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

[Arjan van de Ven]

> 
> 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 wkr.

And your __alway_inline example.. that's something that really is kernel
internal and shouldn't be exposed to userland. 


I think the "problem" really is not there if
1) we only use __ symbols like we do today for non-structs
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.
3) keep the userspace exposed stuff as small as reasonable. Your
   __always_inline example doesn't make that cut. A struct used as
   ioctl of a subsystem/driver in the header specially for that 
   subsystem/driver does.



-
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/