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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/