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

Kyle Moffett
2006-03-26T15:23:28Z

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