Messages in this thread | | | From | Kyle Moffett <> | Subject | Re: [RFC] Splitting out kernel<=>userspace ABI headers | Date | Sat, 3 Sep 2005 02:05:03 -0400 |
| |
On Sep 3, 2005, at 01:57:26, H. Peter Anvin wrote: > Kyle Moffett wrote: > >>> The world would be so much nicer a place if user space were free >>> to #include linux/* header files rather than keeping a >>> per-project private copy of all kernel structs of interest. >> Exactly! This is why I want to create kcore/* and kabi/* that >> define the appropriate types, then both userspace and the kernel >> could use whatever types fit their fancy, defined in terms of the >> __kcore_ and __kabi_ types, which could be _depended_ on to exist >> because they are guaranteed not to conflict with other namespaces > > Agreed. We should use well-defined namespaces that won't conflict. > However, I think the __[us][0-9]+ namespace can be considered > well-established.
True, however, IMNSHO it would be much better if the kcore/kabi stuff had a _consistent_ namespace as well. If every macro begins with "__KABI_" and every type and function with "__kabi_" (With a few function-like macro exceptions, of course), then it is trivial to see where it originally came from and provides a standard naming scheme that external parties can kind of rely upon. It also means there are fewer exceptions to remember when coding. My thought for the __[us][0-9]+ types is that they should still be defined in linux/types.h for compatibility (outside of __KERNEL__) and based off the __kabi_* types.
Cheers, Kyle Moffett
-- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- C.A.R. Hoare
- 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/
| |