Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[Alexandre Oliva <aoliva@redhat.com>]

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

> On Tue, 30 Nov 2004, Alexandre Oliva wrote:
>> 
>> - move anything that is not protected by #ifdef __KERNEL__ to the
>> ukabi header tree, adding an include in the beginning of the original
>> header that includes the ukabi header.

> No. I want stuff that goes into the ABI tree to be clearly _defined_ to be 
> user-visible. Not a "let's move it all there and then prune it". 

Right.  Which brings us to my second bullet.  I *knew* I should have
made it the first :-/

> Also, "ukabi" just isn't going to fly as a name. It's also not as simple 
> as you seem to think, since a lot of these ABI things are architecture- 
> dependent, which apparently all you guys have totally ignored. 

Looks like you missed the post that started this thread.  It *did*
mention machine-independent and machine-specific user headers.

> I've suggested "include/user/" and "include/asm-xxx/user", which handles 
> architecture-specific parts too. I'm ok with doing it the other way 
> around, ie "include/user/" and "include/user/arch-xxxx".

As I pointed out, `user' is a very bad name.  As you said yourself,
we're talking about the *kernel* ABI.  So what's `user' supposed to
mean?  Was I so successful in my arguments that you now see it as the
userland ABI? :-)

>  (a) it can't break anything (ie the old location still includes the new 
>      one, exactly the same way)

You mean it can't break anything in a kernel build, or it can't break
anything except for userland apps that abused kernel headers and used
to get away with that?

>  (b) there are people who will actually take _advantage_ of that 
>      particular file (ie "just because I think so" doesn't fly).

People who currently get to maintain duplicates of these header
contents will take immediate advantage of these changes, since they
will no longer have to maintain the duplicates.  This is a major step
forward in terms of maintainability for everybody else, at no expense
to the kernel, that now gets to explicitly (as opposed to implicitly)
document what is the ABI it's willing to comply with.  It's a win for
both ends.

-- 
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}