Re: [PATCH] linuxabi

Rob Landley
2003-10-04T03:40:12Z

On Friday 03 October 2003 02:36, Eric W. Biederman wrote:
> Andries Brouwer <aebr@win.tue.nl> writes:
> > On Thu, Oct 02, 2003 at 08:39:50AM -0600, Eric W. Biederman wrote:
> > > This is a 2.7 project.
> >
> > I disagree. This is unrelated to kernel development, just like working
> > on sparse is unrelated to kernel development.
>
> Granted. The major point is that it requires a development cycle
> before it is ready. Only if this is to be maintained as part of
> the kernel is it needed to be 2.7 work.

Um, what's the point of having linux abi exort header files that are NOT part
of the kernel?

The theory here is that _some_ of the definitions in the kernel headers define
interfaces with userspace. Structures passed to fcntl or ioctl, constants,
etc. The kernel has to have copies of these definitions for its own use,
just as much as userspace does. (It has to get the data from and put the data
into these structures, doesn't it? How can it do this without a defiition of
these structures? An interface has two sides, and the kernel side of that
interface needs the abi definitions to provide the abi.)

The other 99% of the kernel headers should NOT get included in userspace
programs. This is the reason that, way back, #ifdef KERNEL was put in there
in the first place, with the ABI stuff being anything that was outside the
#ifdef. This solution sucked eggs for fairly obvious reasons, but rather
than separate out the ABI definitions into their own header files shared by
kernel and user space, the advice from on high became "just cut and paste out
the bits you need". This solution sucked different eggs. Any library that
talks directly to the linux kernel needs to have access the kernel ABI, and
manually extracting it from the kernel header files is a maintenance
nightmare. Even if you abstract this away into a library, the LIBRARY still
needs to do it. You've just moved the problem.

Some people here have argued variants of "tracking what the linux kernel
exports to userspace is somebody else's problem". I.E. the linux kernel
can't be bothered to keep track of what it exports to userspace. That just
gives me a warm fuzzy feeling all over, that does...

> My point is that we need to cleanly handle the fact that glibc
> defines it's own abi that is not equivalent to the kernel abi.
> A linux specific namespace does that. After libc is done with
> the definitions users will still use MS_RDONLY.

Does anything other than glibc have this problem? (Does uclibc have this
problem? cdrecord?)

Rob