Joerg Schilling has a complaint
. If you try
to include the kernel header file include/linux/scsi/scsi.h
user-space program, a number of compilation errors are the result. Joerg
had reported the problem a good year ago, but it remains unfixed.
"Is there no interest in user applications for kernel features or is
there just no kernel maintainer left over who makes the needed
The initial reaction from the kernel developers was rather unsympathetic.
In the modern world, applications are not supposed to be including kernel
header files directly. Instead, they should use whatever sanitized version
is provided by glibc. Anybody who tries to include kernel headers into
user-space applications should not complain when things fail to work.
In the real world, however, such a simple answer is not sufficient. The
kernel exports a vast number of interfaces; consider just the various
ioctl() calls offered by innumerable device drivers and
subsystems, for example. Even if the communications between the kernel and
glibc developers were better than they are, it would be difficult to expect
the glibc people to keep up with every obscure interface that gets added to
the kernel. As David Miller put it:
Even if one is of the opinion that nobody should be including the
kernel headers, you must fully realize that as a matter of
practicality people absolutely must do this to use many kernel
interfaces to their full extent. Suggest changes to fix the
problems, but just saying "don't include kernel header in your user
apps, NYAH NYAH NYAH!" does not help anyone at all.
For the short term, David suggests that the relevant kernel header files
should simply be fixed so that they work when included into user-space
In the longer term, there is clearly a need to get a better handle on what,
exactly, the interface between kernel and user space is. One approach that
is being taken in this direction is to push kernel interfaces into virtual
filesystems such as sysfs. Interfaces defined in this way are explicit and
visible, and they rarely require any C header file support at all. The
virtual filesystem approach works well in many cases, but it is unlikely to
replace other kernel interfaces entirely.
So it is still necessary to, somehow, better define the kernel's binary
application interface. To that end, Andries Brouwer has posted a patch bringing back the idea of a separate
set of "Linux ABI" include files. In this rendition, there would be a new
include/linuxabi directory (along with architecture-specific
variations) which would contain header files defining constants and data
structures used for communication with user space. They would be
specifically intended to be included from user space. Andries starts by
removing the various mount option flags from <linux/fs.h>
and putting them in <linuxabi/mountflags.h>.
This idea has come up before, but it has never been adopted in the mainline
kernel. Getting to a point where a significant part of the kernel binary
interface is documented in include/linuxabi will clearly take a
long time. Rearranging the kernel include file hierarchy may not be an
appropriate thing to do at this point in the development cycle. It might
not be a bad idea for early in the 2.7 series, however.
to post comments)