Re: Simple header cleanups

["H. Peter Anvin" <hpa@zytor.com>]

Followup to:  <Pine.LNX.4.64.0604271656390.3701@g5.osdl.org>
By author:    Linus Torvalds <torvalds@osdl.org>
In newsgroup: linux.dev.kernel
> > 
> > Normal userspace programs will simply not care about the contents of the 
> > kernel ABI headers - the libc will present them pretty headers adhering 
> > to all past, current and future standards.
> 
> As long as that is clear - that the kernel ABI headers are _never_ seen by 
> normal programs, even indirectly #include'd from the standard include 
> headers.
> 

For some of them, there isn't really any reason not to; in particular
when it comes to things like ioctl constants and structures that
describe what is functionally an RPC interface between the user-space
application and the kernel -- the library couldn't realistically
intervene even if it wanted to.

This is also by orders of magnitude the fastest evolving part of the
kernel ABI.

When it comes to more serious stuff like "struct stat" it should be
pretty obvious any "struct stat" the kernel exports is going to be
wrong.  klibc, which cares about size and not ABI stability, could
export it directly, but it still wants to be able to *choose* which
"struct stat" to use -- on most platform, it's what the kernel calls
"struct stat64", except with a 32-bit dev_t instead of a 64-bit
unsigned long long for st_[r]dev, plus of course appropriate padding.

One solution would of course be to have a purely declarative language
for that stuff.  A C program won't use it because a C program *can't*
use it without further processing, and the declarative language
processor is the ideal place for such stuff.  In that scenario even
the kernel would have to use a processed version of the ABI
declarations.

An intermediate solution might be to take sparse, and something like
it, and use it as the declarative language processor.  Then the kernel
could still use them as C, but the library would have an easy way to
process them.  The risk is that something might not.

What David has done is yet one step down from this in ambition level,
but at least he's gotten the ball rolling.

	-hpa
-
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/