Kyle wrote:
> This would make life a million times easier for the UML people,
> the glibc people, the klibc people, and the linux-libc-headers
> maintainer
Spraying wildly from the hip with my Uzi ...
If the several groups you list would all benefit from some particular
form of kernel headers that is not what we have now, then why don't
they pool together and have one person maintain such a header set,
keeping it current with the kernel. It could even (Lord Linus willing)
be given a place to live in the kernel source: "the kernel-user API,
as seen from userland".
But trying to cram that header view into the same files as the kernel's
internal view of itself seems like a fools errand.
Heck, on a good day, you might even get an occassional kernel patch
that included the corresponding kernel-user API header change, rather
as happens now with the Documentation files. And efforts to keep
stuff usable with C++ code could be welcomed on such headers, where
they are rejected for kernel internals.
Bottom line - leave all existing kernel files as they are, and add
a new subdirectory, for these new header files. Agree amongst
yourselves (the above named groups) on a MAINTAINER, and start
crafting the headers you need, in the style to which you wish to
become accustomed.
Don't confuse theory and practice. In theory, these new headers
present information already known to the kernel, so should not
be separate. But in practice, the demands are sufficiently different
that it will be easier to maintain as a separate set of headers.
Better two simple answers than one convoluted answer.
... hopefully my stray bullets didn't harm any innocents.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |