Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[Alexandre Oliva <aoliva@redhat.com>]

On Nov 30, 2004, Linus Torvalds <torvalds@osdl.org> wrote:

> Wrong. They'll _still_ have to maintain duplicates, since they can't rely
> ont he end-user to have a recent enough kernel.

No.  They just won't have the headers for the newer kernel installed
on their system.  They stick with the kernel ABI headers provided by a
baseline kernel, and that's probably from an older kernel tarball.

> It's just that they can hopefully start _copying_ their dupliates more 
> easily.

It's still the headers from the kernel, copied or not.  From a
different, baseline version, maybe.

> At RH you may see only the case where people do a whole-system upgrade. 

I personally don't care about the case you perceive as the Red Hat
case, because I work on embedded systems development, in a different
organization within Red Hat than the people who develop Red Hat
Enterprise Linux and Fedora.  So yes, in the case that actually
benefits me, it's even more of a whole-system thing, since for our
group it's *the* kernel, not *a* random kernel version.  It's the
kernel we port and ship to the customer, and the corresponding
kernel<->userland ABI.

That said, I do understand the issues of kernel baseline ABI settings,
or at least part of them.  I know you don't want to assume the
presence of a certain system call just because you're running a kernel
that implements it.  In fact, I know you don't want to assume the
presence of a system call just because it's defined in linux/unistd.h.
As long as the userland software keeps this distinction in mind, I
don't see why taking the latest kernel<->userland ABI headers, that
describe the newest system calls and any corresponding data
structures, could hurt anything.  In fact, if you don't have the
corresponding system call numbers and data structures, you can't
possibly take advantage of the new syscalls even if they happen to be
available, unless you duplicate the syscall numbers and data structure
definitions in your own code, which, from a software engineering
standpoint, is bad.

Of course, badly written software can assume the syscalls are present
just because their numbers are given, and then people who rely on such
bad software lose, but such is the nature of bad software.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}