lkml.org 
[lkml]   [2006]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC][PATCH 1/2] Create initial kernel ABI header infrastructure
Date
On Apr 1, 2006, at 19:22:13, Randy.Dunlap wrote:
> On Wed, 29 Mar 2006 22:26:41 +0000 Pavel Machek wrote:
>>> 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:
>>
>> __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).

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.

Thanks for the advice!

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/

\
 
 \ /
  Last update: 2006-04-03 14:08    [W:0.169 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site