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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
