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

Pavel Machek
2006-04-02T10:33:02Z

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