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

From: Kyle Moffett
Date: Sun Mar 26 2006 - 10:20:30 EST


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/