Kernel headers and user space
Unfortunately, things do not always work that way, and some user-space programs still end up including kernel headers directly. These programs may simply be old, or they may need access to declarations which are not available in the C library include files - strange ioctl() codes, for example. So the kernel code still tries to make it possible for user space to include some header files. In these files, kernel-specific code is contained within #ifdef __KERNEL__ blocks and hidden from user space. This technique works, but it is brittle and adds extra cruft to the kernel code base. Intermixing internal kernel definitions with those needed by user space also makes it easy to break the user-space API.
The kernel developers have, for years, wanted to improve this situation. The latest attempt came in the form of this RFC from David Howells. This proposal would create some new directories in the kernel source tree: include/user and some architecture-specific variations (such as include/user-i386). When a portion of a kernel header file is found to be needed by user space, it would be placed into a separate file in one of those directories, and the new file would be included into the old one. At this point, the definitions needed by user space will have been separated out, but no visible changes will have been made; user space can still include the old file and get what it needs.
At some future point, when user space is deemed to have been fixed, all of the __KERNEL__ references could be removed from the old files. At that point, any application still including the internal header files would break.
One part of the idea which did not get very far was using standard C types (such as uint16_t and such) for the user-kernel interface. The problem with that idea is that the kernel cannot count on those types being consistently defined for all configurations, and cannot create its own definitions for the standard types. So the kernel/user interface must continue to be defined using kernel-specific types (__u16 and such).
Linus was not all that enthusiastic about the idea in general. To him, it looks like an exercise in rearranging things without specific goals and with the possibility of breaking things which work now:
What he would like to see is more specific discussions which identify
specific, problematic header files and what will be done to fix them. In
the end, the header files might just get split up in the way described by
Mr. Howells. It is more likely to happen as a long and slow process,
however, and not as a massive, coordinated reorganization.
| Index entries for this article | |
|---|---|
| Kernel | Coding style |
| Kernel | Include files |
Posted Dec 4, 2004 0:41 UTC (Sat)
by giraffedata (guest, #1954)
[Link]
I hate ifdef __KERNEL__. But I hate even more the proposition that a user space program should not include a kernel header file. The C library is itself a user space program, so the rule that a user space program has to go through the C library obviously isn't logical. And the GNU C library is an optional tool, not an official part of the kernel interface (if it were the latter, I would expect to see it packaged with the kernel).
It's common practice in C programming to declare as much of an interface as possible in a header file and have the code at both ends of the interface use the same file to ensure that they agree on the interface. That Linux has never had an identifiable set of interface header files to declare its system call interface seems to me to be a major engineering weakness.
I thought Howell's proposal was a natural.
Kernel headers and user space