Defining the kernel/user space interface

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:

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 programs.

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.