Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[Tomas Carnecky <tom@dbservice.com>]

Grzegorz Kulewski wrote:
> Ok, so maybe do it in this way:
> 1. common headers (included by 2. and 3.)
> 2. kernel headers (things only for kernel + included 1.)
> 3. userspace headers (things only for userspace + included 1.)

Are there really any definitions that belong _only_ to userspace?
AFAIK all that is in the kernel sources is used by the kernel, so
there are no headers that would fit into your category 3. There is
no reason to put such things into the kernel sources.

> Are you talking about breaking userspace (API and ABI) compatibility? 
> And possibly breaking compatibility with older versions of standards? I 
> do not think it could happen. (Well at least not for common widely-used 
> APIs).
> 
> Instead we can place such userspace only hacks in 3.

The API can be changed, I don't see any problems with the API
compatibility, if you document all changes then it's no problem for
the developers to change their code.
And the ABI? Well, I compile my kernel by myself, as I do all my 
userspace (gentoo). And the distributions still could define
__DEPRECATED__ (or something similar).

I mean.. come on.. how hard is it to change some lines of code,
some structure names, some function arguments.
I know that there's a problem if you have binary only files, but
I doubt that anyone is running a exe that was compiled for against
kernel 2.0 and every big company compiles their projects against each
stable kernel line.
Oh.. and I forgot, you usually don't include the kernel headers in your
'hello world' program, most of the applications use (g)libc, one big
library, so you'd need to change only very few projects, although I
admit that can be rather big projects, but still...

BTW, how much smaller would the kernel be if we removed all the
backwards compatibility? I mean the size of the compiled kernel
image.

tom