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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux