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

[Kyle Moffett <mrmacman_g4@mac.com>]

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/