Messages in this thread | | | From | Kyle Moffett <> | Subject | Re: [RFC][PATCH 0/2] KABI example conversion and cleanup | Date | Sun, 26 Mar 2006 19:40:14 -0500 |
| |
On Mar 26, 2006, at 18:06:48, Eric Piel wrote: > The real problem of sharing the same headers between kernel and > KABI is that it will end up by having to re-implement the "#ifdef > __KERNEL__"'s. Have a look at Kyle's second patch "Generalize > fd_set handling across architectures". Some headers had a different > version of the __FD_*() macros depending on the compiler. That's > something you may want to have in the implementation but definitely > not in the specification.
Actually, I think it's the other way around. The <kabi/*.h> files should (eventually) be useable in basically any compilation environment thrown at it. This means it should work from C and C++, using GCC, ICC, or some custom barely-standards-compliant compiler. I didn't bother with that part right now, since I still want to try to reuse the generic bitops if possible, but it's something I plan to address in future versions of the patchset (see below).
> In this situation, Kyle handled it nicely by writing versions > compatible with any compiler.
Eh, not really. "__inline__" is GCC-specific and probably won't work in other compilers (unless you did "#define __inline__", which would bloat the code a lot).
This case highlights something else I'd like to do. A good chunk of the functionality in the Linux kernel works both in userspace and kernelspace, and some of those arch-specific primitives (like the inline bitops) would be useful in defining the kabi headers. According to Jeff Dike, UML would like access to some of that stuff unrestricted by __KERNEL__ too. In all of those cases, it's not an ABI and all the users are in-kernel so it could be changed at will. I'd like to try to put some of that into a "klib" directory (though with dependencies crossing between kabi and klib) so that it could be used in kabi and UML without duplicating functionality. Naturally much of that would be C-only and depend on GCC, but I would have to be careful that the kabi portions used least-common-denominator functionality.
That brings up one final point: Does anybody actually use any compilers on Linux other than GCC?
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/
| |