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

[Kyle Moffett <mrmacman_g4@mac.com>]

On Mar 26, 2006, at 07:32:31, Arjan van de Ven wrote:
> On Sun, 2006-03-26 at 06:54 -0500, Kyle Moffett wrote:
>> Create initial kernel ABI header infrastructure
>
> it's nice that you picked this one;
> for this you want an arch-generic/stddef32.h and stddef64.h
>
> and have arch-foo just only include the proper generic one..

I plan to add a lot of other definitions to this file later on.  For  
example different architectures have different notions of what a  
__kernel_ino_t is (unsigned int versus unsigned long).  I may rename  
this file as types.h, but from looking through the code I figure I'll  
have enough general purpose declarations about "This architecture has  
blah" that a separate stddef.h file will be worth it.

> (and... why do you prefix these with _KABI? that's a mistake imo.  
> Don't bother with that. Really. Either these need exporting to  
> userspace, but then either use __ as prefix or don't use a prefix.  
> But KABI.. No.)

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.  The GCC  
manual says we should be able to write this:

inline __attribute__((__always_inline)) int increment(int x)
{
	return x+1;
}

Except when compiling the kernel headers turn that into this (which  
obviously doesn't compile):
inline __attribute__((__attribute__((always_inline)))) int increment 
(int x)
{
	return x+1;
}

As a result, I kinda want to stay away from anything that remotely  
looks like a conflicting namespace.  Using such a unique namespace  
means we can also safely do this if necessary (Since you can't  
"typedef struct foo struct bar"):

kabi/foo.h:
   struct __kabi_foo {
   	int x;
   	int y;
   };

linux/foo.h:
   #define __kabi_foo foo
   #include <kabi/foo.h>

drivers/foo/foo.h:
   #include <linux/foo.h>
   void func()
   {
   	struct foo = { .x = 1, .y = 2 };
   }

Cheers,
Kyle Moffett