Re: Upcoming ABI Breakage in RELENG_7

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 others
> > > 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 >= 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.
> 
> Question is what is the best way to determine which programs (if any) depend 
> 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.

-- 
                                                Ken Smith
- From there to here, from here to      |       kensmith_at_cse.buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |