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