lkml.org 
[lkml]   [2006]   [Apr]   [2]   [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 2, 2006, at 06:32:23, Pavel Machek wrote:
>> 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.

At worst it would just go from "struct dirent" to "struct
__kabi_dirent". One reason for this distinction as I believe was
highlighted in another email was so that eventually if necessary libc
could export a "struct dirent" not the same as the kernel one, and
translate between them internally. That would be difficult or
impossible now, given the way the kernel exports "struct dirent"
directly. I don't remember the specific case where this would have
been convenient, but I seem to recall it was mentioned in one of the
earlier iterations of this thread.

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

I still disagree with you on this point, but I'll save the arguments
for when I have some submittable patches I'd like to get feedback
on. I'm also fairly positive that in comparison to the ugliness in
some of the necessary C89-compatibility macros, the __kabi_ prefix
would be insignificant, but let's leave that discussion for another
time as well.

Cheers,
Kyle Moffett

In any case, for reference, here are a few of the specific arguments
for support for other compilers:

On Mar 28, 2006, at 12:28:47, Daniel Jacobowitz wrote:
> If you want glibc to ever include these things, they had better be
> portable C and work without GCC. Otherwise it's a non-starter.
> Only GCC may be used to build glibc, but it deliberately supports
> any conforming C compiler to build userspace code.

On Mar 28, 2006, at 12:56:27, Jesper Juhl wrote:
> Other compilers do exist.
>
> Over the years I've personally used a few to compile userspace apps
> for different projects (though never for compiling the kernel).
>
> Some of the compilers I have personally used for userspace apps on
> Linux include: gcc, icc, lcc, tcc
> Others that I know of but have never used include: sdcc, Compaq C
> for Linux, Open Watcom, vacpp, XL C/C++
>
> and I'm sure many more exist...

-
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:37    [W:0.148 / U:0.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site