From owner-freebsd-current@FreeBSD.ORG Wed Jul 30 14:55:05 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A26E41065671; Wed, 30 Jul 2008 14:55:05 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 7952A8FC08; Wed, 30 Jul 2008 14:55:05 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id m6UEstZi019923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2008 10:54:55 -0400 (EDT) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: David Southwell In-Reply-To: <200807300755.30414.david@vizion2000.net> References: <200807300247.34948.david@vizion2000.net> <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <200807300755.30414.david@vizion2000.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7QjMtSdC065sW1EWh7sj" Organization: U. Buffalo CSE Department Date: Wed, 30 Jul 2008 10:54:55 -0400 Message-Id: <1217429695.63703.36.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1336; Body=0 Fuz1=0 Fuz2=0 X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on phoebe.cse.buffalo.edu Cc: Ian FREISLICH , freebsd-stable@freebsd.org, freebsd-current Subject: Re: Upcoming ABI Breakage in RELENG_7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2008 14:55:05 -0000 --=-7QjMtSdC065sW1EWh7sj Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-07-30 at 07:55 -0700, David Southwell wrote: > On Wednesday 30 July 2008 07:27:27 Ian FREISLICH wrote: > > David Southwell wrote: > > > On Tuesday 29 July 2008 08:45:45 Ken Smith wrote: > > > > Normally the FreeBSD Project tries very hard to avoid ABI breakage = in > > > > "Stable Branches". However occasionally the fix for a bug can not = be > > > > > > Sometimes information gets posted to this list on the assumption that > > > everyone understand what the writer means. > > > > > > This is one of those occasions!! > > > > > > For those of us who are not as well informed and experienced as other= s > > > could someone please explain what is meant by an ABI breakage, its > > > implications and how to deal with them. > > > > Within a major release, the project tries very hard to maintain > > Binary Interface campatibility, or stability. In fact as far as I > > know, this is where the name "Stable Branch" originates. > > > > What this means is that a binary compiled on 7.0-RELEASE should > > continue to work without needing to be recompiled over the lifetime > > of the 7 branch. > > > > ABI breakage that Ken refers to here means that a change required > > to fix a bug cannot be made while maintaining binary compatibility > > with previous versions. Any program that makes use of (I'm guessing) > > fcntl(2) or flock(2) that runs on 7.0, will not run on >=3D 7.1 without > > being recompiled. > > Actually not quite, and that's why Konstantin mentioned I made a slight mistake in my original announcement. ABI stands for *Application* Binary Interface but (sorry) that's not quite what is being broken here. It is a KBI (Kernel Binary Interface) that's being broken. The difference is that the data structures being changed are strictly internal to the kernel. Back in the days of "strictly monolithic kernels" when the only way to get something into the kernel was to rebuild the whole kernel and reboot with it this sort of thing was less of a concern. But now that "kernel modules" can be loaded while the machine is up and running we need to be a bit more careful about announcing when a very important kernel data structure gets modified in such a way that already-compiled modules might not be compatible because of, as someone else mentioned, that very important data structure changing in size or the elements inside that structure changing position. So because this is a KBI being broken it should NOT have any impact on user-level executable files. It should only impact loadable kernel modules that deal with filesystems. IF this change did indeed change user-level programs to the degree mentioned above that would "raise the bar" *dramatically* on whether we would consider the fix worth the fall-out that would occur. Frankly I think we would have rejected the fix if it were that drastic. > Thanks that is very concise and very helpful. >=20 > Question is what is the best way to determine which programs (if any) dep= end=20 > upon fcntl or flock on a running system? No need to. :-) But one way to do it if you ever needed to is with nm(1), something like: nm file | grep fcntl though that would only tell you if that executable directly calls fcntl(2) itself (functions inside libraries may wind up calling fcntl(2) so if you really needed to be thorough you would need to also check the libraries the executable is linked against, ldd(1) can help you figure out what those are). There are likely better/easier ways to do it. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-7QjMtSdC065sW1EWh7sj Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkiQgLYACgkQ/G14VSmup/ZuiwCgl6dF2x008XX0DA+m6VWaPXvt 20wAoI3rlPXyoI6Ayrjssypg22HvYngg =Li67 -----END PGP SIGNATURE----- --=-7QjMtSdC065sW1EWh7sj--