Re: [RFC] Splitting out kernel<=>userspace ABI headers

[Kyle Moffett]

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