Re: [RFC][PATCH 1/2] Create initial kernel ABI header infrastructure

[Kyle Moffett]

On Mar 26, 2006, at 09:39:28, Arjan van de Ven wrote:
> > According to the various standards all symbols beginning with __  
> > are reserved for "The Implementation", including the compiler, the  
> > standard library, the kernel, etc.  In order to avoid clashing  
> > with any/all of those, I picked the __KABI_ and __kabi_ prefixes  
> > for uniqueness.  In theory I could just use __, but there are  
> > problems with that too.  For example, note how the current  
> > compiler.h files redefine __always_inline to mean something kinda  
> > different.
>
> well... the "problem" is there today, and... it's not much of a  
> problem if at all; there's just a few simple rules to keep it that  
> way which seem to work.

The current rules work for things kept completely private to the  
kernel.  If we start exporting things into the guts of libc, we can  
expect that those guys have _also_ been using all sorts of double- 
underscore symbols in conflicting ways.

> And your __alway_inline example.. that's something that really is  
> kernel internal and shouldn't be exposed to userland.

Yes, but it illustrates how a supposedly-innocuous double-underscore  
symbol actually conflicts with a GCC builtin, and that's just GCC!   
That's not including the massive "The Implementation" codebase that  
is GLIBC.

> 2) avoid including kernel headers in kernel headers as far as  
> possible.  This means, that if an application wants to use MTD  
> struct "struct mtd_foo" it will have to include the MTD header, but  
> that he otherwise never gets it. Eg all such symbols are in a "Yes  
> I really want it" header.

This is Hard(TM).  Take a look at the interdependent mess which is  
kernel.h, or sched.h.  Feel free to submit patches :-D  That's  
actually part of the reason why I'm trying this kabi/*.h bit.  I  
think that if I can pull out userspace-required struct definitions  
from the rest of the code, we'll notice that some of the header files  
don't need as many dependencies anymore and can be cleaned out a bit.

I've also been looking at GCC's "precompiled header" stuff.  I think  
that a single kabi.h file that includes all other kabi headers,  
precompiled to "kabi.h.gch", could potentially speed up a portion of  
the linux kernel build by removing a lot of text parsing.  I can't  
tell for sure till I've cleaned up more crap and done benchmarks, but  
I'm willing to give it a shot. :-D

Cheers,
Kyle Moffett

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