> What I mean by sanitized: break headers into two halves, one which
> contains only definitions and -- with appropriate #ifdef's -- can be
> included by userspace, and one which contains static inline code, which
> includes the first half and which should never ever be even looked at by
> userspace. Breaking up fs.h would be the first step towards sanity. It's a
> big job, maybe it's a 2.3 job and 2.1/2.2 should be patched as much as
> possible with #ifdef's, though that will be ugly. We shouldn't have gotten
> here to begin with.
That I agree with 100%. For example, the autofs code contains
linux/auto_fs.h and fs/autofs/autofs_i.h which are much that way.
I've been thinking about this for a while myself, and it would be
interesting to put something like a major version number and datestamp
into the beginning of the interface header file:
/*
* linux/ext2fs.h
*
* INTERFACE_VERSION=1, DATECODE=981012
*/
Then I'd include a copy of ext2fs.h in e2fsprogs, and have an autoconf
macro which parses out the INTERFACE_VERSION and DATECODE and then
either uses the version in the linux source tree or the one bundled in
with e2fsprogs, whichever has the newer DATECODE.
The INTERFACE_VERSION would be a major version number, and if the
INTERFACE_VERSION of the kernel source tree didn't match, probably the
right thing to do would be to have the autoconf macro issue a warning
message, and then use the version of the header file bundled with the
user program, since presumably that's what the sources for the
application was expecting.
This has a couple of nice properties. It means that there is only a
single master source file describing the kernel<->user interface, so you
avoid difficulties where the the kernel definition of the interface and
the application definition of the interface drift. It also means that
compilation of the user program isn't dependent on the having the latest
version of the kernels installed on the build machine.
- Ted
P.S. I prefer to use linux/foo.h for the public interface, and
linux/fooP.h for the kernel-private information; hence linux/serial.h
and linux/serialP.h. Other people like to use linux/foo_i.h for the
publically exported interface. This is just a matter of taste, but it
seems nicer to me to reserve the "uglier" name for the internal header
file, and to use the "nicer" name for the public header file.
-
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/