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

[Pavel Machek]

Hi!

> >>__KABI_ everywhere will just make your headers totally  
> >>unreadable.  Please don't do that.
> >
> >Ack, I agree.
> 
> Let me reiterate two facts:
> 
> (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).
> (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.
> 
> 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?  If you have some way, I'd be interested to hear it, but  
> as a number of those compilers are commercial I'd have no way to test  
> on them (and I suspect most people on this list would not either).

No, you should just not care about anything but
gcc. intel-cc-version-0.3.2.1.2.5 could use __kabi_struct_dirent or
whatever, and collide anyway. By adding __kabi you just make it less
likely.

I believe __ is enough. If there's one conflict with some obscure
compiler, we can simply fix the conflict (or even fix the compiler
:-).

If you feel __ is too dangerous, you may go __k ... It will not look
as ugly as __kabi_ , and should be very safe.
								Pavel

-- 
Picture of sleeping (Linux) penguin wanted...