kernel ABI [was something about Compile Bogons...]

Brad Hards (bhards@bigpond.net.au)
Thu, 25 Jul 2002 18:23:55 +1000


On Thu, 25 Jul 2002 17:57, Russell King wrote:
> On Thu, Jul 25, 2002 at 02:32:52PM +1000, Brad Hards wrote:
> > Some applications talk to the kernel (eg via ioctl()). This is related to
> > the kernel version that is running (not anything to do with the libs).
>
> And ioctl() is an evil interface, and anything which changes in an
> already defined ioctl is an ABI change, which aren't allowed in stable
> kernel series.
ioctl() is a damn evil interface that we are stuck with.
Changing an already defined ioctl isn't a sufficient condition.
If you have a program that is testing for a certain kernel
capability (ioctl, socket, whatever), and it is present in the
headers, then it needs to be present in the kernel that the
program will run under. So you can't add anything to the
ABI (as described by the headers) in a stable series either.

> > 3. Things that are related to the kernel that is running.
> > This is probably /usr/include/linux
>
> No. Search the lkml archives. You'll find several people, including
> Linus telling people otherwise.
I didn't express it well. My point is that the include files should be
refactored to provide only the kernel ABI in /usr/include/linux.
If it isn't part of the kernel ABI, then it isn't strictly part of Linux,
and the naming should support that.

Then /usr/include/linux (or linux-abi, whatever) really _should_ be
a symlink to the currently running kernel headers describing the
ABI.

But certainly not the way it is now, where symlinking /usr/include/linux
to /usr/src/kernels/linux-2.x.y.z-rcA/include is the path to madness.

-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/