There seems to be a lot of flameage/discussion about kernel headers, and
their involvement with user space apps. So far, the two sides seem to be:
never, ever use a kernel header in a user space app, and user space apps
need device driver headers to know how to interact with the hardware. Since
neither point of view is in direct conflict, I propose this solution:
Device drivers that export functionality to user land should have a set of
internal headers in the Linux kernel include directory, and a set of headers
that define the exported interface. If the interface changes, the exported
headers are updated. If the internals are updated, the internal headers are
updated. Programs compile and run without causing crashes :-)
For other kernel internals, such as the VM layer, VFS, etc, two sets of
headers (one internal, one interface) would seem to also make sense. Since
most of the kernel internals are internal, there shouldn't be too much
duplicate of effort. And any duplicate can likely be avoided by carefully
thinking out the interfaces and definitions.
The largest change to existing headers would likely be splitting the #ifdef
wrapped single .h files into two .h files. Of course, this won't solve the
problem of people using C++ reserved words in their headers, but the naming
of variables can always be changed easily.
-- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:14 EST