Re: [PATCH] linuxabi

[Rob Landley <rob@landley.net>]

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