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

[Arjan van de Ven <arjan@infradead.org>]

On Sat, 2006-04-01 at 21:42 -0500, Kyle Moffett wrote:

> (1)  The various C standards state that the implementation should  
> restrict itself to symbols prefixed with "__", everything else is  
> reserved for user code (Including symbols prefixed with a single  
> underscore).

user code in this context includes, in my interpretation, headers for
specific ioctl structures and such (eg direct included headers; headers
that those headers include are a different matter) that the user wants.

Which is the vast majority of the kernel abi.
Exceptions are things like __u64 which are almost always "indirectly"
included. Eg the app wants "struct foo_ioctl" and foo_ioctl happens to
contain an __u64 which needs types.h


> (2)  GCC predefines a large collection of symbols, macros, and  
> functions for its own use, and this set is not constant (just look at  
> the number of new __-prefixed symbols added between GCC 3 and 4.  In  
> addition, we're not just compiling this code under GCC, but people  
> will also be using it (hopefully unmodified) under tiny-cc, intel-cc,  
> PGI, PathScale, Lahey, ARM Ltd, lcc, and possibly others.  It  
> probably does not need to be stated that for something as userspace- 
> sensitive as the KABI headers we should not risk colliding with  
> predefined builtins in any of those compilers.

the good news is that as kernel we have SOME power ;)
people who make compilers like that stay away from symbols the kernel
defines. Especially gcc is very careful in its namespace use and tends
to be very different from what linux kernel uses

> So my question to the list is this:
> Can you come up with any way other than using a "__kabi_" prefix to  
> reasonably avoid namespace collisions with that large list of  
> compilers?

First of all be realistic. Don't do silly things for places where it
doesn't matter. Again the ioctl structs come to mind.
Second, names the kernel ALREADY claims are of course free to use as
well; all those compilers ALREADY stay away from those.

What is left if you take those two big ones out of the picture?


> Of course, if the general consensus is that supporting non-GCC is not  
> important, then that's ok with me.  Judging from the number of  
> negative responses my earlier "[OT] Non-GCC compilers used for linux  
> userspace" got, however, that doesn't seem to be the case.

there is another dynamic; those other compilers in general try to
emulate gcc to a large degree, usually a very large degree. So the
"problem" you see is a lot smaller than you think.