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
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. |
...
