From owner-freebsd-standards@FreeBSD.ORG Tue May 31 17:56:45 2005 Return-Path: X-Original-To: standards@freebsd.org Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41CD816A41C; Tue, 31 May 2005 17:56:45 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (berlin-qwest.village.org [168.103.84.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E12F43D4C; Tue, 31 May 2005 17:56:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j4VHrcDt064683; Tue, 31 May 2005 11:53:45 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 31 May 2005 11:53:38 -0600 (MDT) Message-Id: <20050531.115338.74685129.imp@bsdimp.com> To: des@des.no From: Warner Losh In-Reply-To: <86k6lfbafu.fsf@xps.des.no> References: <86fyw32yqm.fsf@xps.des.no> <86k6lfbafu.fsf@xps.des.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: nectar@freebsd.org, standards@freebsd.org, freebsd-arch@freebsd.org, current@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 17:56:45 -0000 > Hajimu UMEMOTO writes: > > Dag-Erling Sm=F8rgrav writes: > > > You can't just bump libpam; you need to bump all the modules alon= g > > > with it, because libpam will only load modules with the same majo= r > > > number as itself. In fact, there is only a single SHLIB_MAJOR fo= r the > > > entire src/lib/libpam tree, in src/lib/libpam/Makefile.inc. > > Thank you for clarification. My patch bumps SHLIB_MAJOR in > > lib/libpam/Makefile.inc. > = > As PAM maintainer, I strongly object. Keep in mind that systemic changes can trump a maintainer's objection. This is a systemic change, so your single objection is not necessarily enough to not do this. However, the issues you raise may be reason enough to revert the systemic change. > > > Is it really necessary to remove the padding? It gives us a lot = of > > > trouble for zero gain. > > I think such cleanup should be done before major release. > = > What do we gain from removing the padding? Is there even a single > practical benefit to doing so? It is for posix compatibility. http://lists.freebsd.org/pipermail/freebsd-standards/2005-May/000869.ht= ml is where to start for an explaination. The question becomes one of do we care enough about 5.x compatibility with our new architectures to preserve it. The RE has indecated that he'd really like to see us do that (ABI stability). Warner