Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[Jean Tourrilhes]

David Howells wrote :
> We've been discussing splitting the kernel headers into userspace API headers
> and kernel internal headers and deprecating the __KERNEL__ macro.

Linus Torvalds wrote :
> On Mon, 29 Nov 2004, Alexandre Oliva wrote:
> >
> > - Linux gets to define the ABI between kernel and userland, and
> >   userland must duplicate the contents of headers in which the kernel
> >   defines the kernel<->userland ABI, tracking changes in them in the
> >   hope that nothing falls through the cracks
> 
> This is unquestionably true. The kernel obviously _does_ define the ABI, 
> and userland just lives with it. At some point you have to track things, 
> just because new features etc just can't be sanely handled any other way. 
> 
> That said, I think we can make the tracking _easier_. 

	Nice discussion, but nobody is discussing my main concern,
even if Linus come close to it.
	On my box, I do have multiple kernels. Some 2.4.X, some 2.6.X,
I may even find some 2.2.X on some of my boxes. Depending on what I
do, and the bug reports send to me, I boot one of these kernel or
another. Because Linus is so productive, I update my kernel
frequently, without changing the user space. I know that some
distributions are also offering various kernel versions, and let the
user choose.
	So, which kernel ABI should be present on my system in
/usr/include/linux and /usr/include/asm ? Should I use the ABI from
2.6.X, 2.4.X or 2.2.X ? Should I take the time to create a sanitised
version of the kernel header every time I install a new kernel, even
though I may revert back to the previous kernel ? Should I recompile
applications using kernel headers at each kernel upgrade ?
	Currently, it doesn't matter, as so few applications are using
those headers, and most changes are highly backward compatible. And
the application that are deeply intimate with the kernel probably do
run-time tracking of features already, so don't really need those
headers...

	However, I believe we need to at least ask this question, even
if I don't think we will come up with a good answer...

	Have fun...

	Jean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/