Messages in this thread | | | From | Kyle Moffett <> | Subject | Re: [RFC][PATCH 1/2] Create initial kernel ABI header infrastructure | Date | Sun, 2 Apr 2006 07:16:15 -0400 |
| |
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/
| |