Kernel Summit 2006: The user-space API
| 2006 Kernel Summit coverage on LWN.net. |
With regard to stability, it was noted that ioctl() calls tend to remain stable, while, for example, /proc and sysfs interfaces have had a distressing tendency to change. Some thought that the assignment of an operation number somehow had the effect of impressing on developers that changes could not be made. There are, however, a couple of other, more plausible arguments that were made:
- Sysfs directly couples the kernel ABI to the internal data structures
used internally. Kernel developers have never accepted limits on the
changes they could make internally, but, with sysfs, all of those
changes are reflected in the ABI - sometimes without the developer's
knowledge. Over time, this coupling is likely to be loosened.
- The Linux system call interface is, for the most part, an implementation of a well-established standard. That standard gave little latitude in how the user-space API could work. With interfaces like sysfs, however, the developers are in uncharted territory. So it is not surprising that more mistakes are made in the creation of the API, and that it tends to be a little more fluid.
Greg also stated that many of the problems with sysfs are the result of errors on the user-space side. Even Greg, in the development of udev, got things wrong. When asked whether this tendency toward errors might indicate that the sysfs interface was inherently unsafe, he replied in the negative. It is hoped that the newer ABI documentation will make the rules for working with sysfs more clear and less error-prone.
The discussion moved on to klibc and whether it should be a part of the kernel. Linus replied that klibc is not interesting by itself - it's more a matter of what interesting things could be done with it. And those interesting things are yet to arrive; Linus is unconvinced by recent efforts to move large chunks of code into user space. There is usually no point, he says, in moving working code out of the kernel, and, in any case, anything which involves shared state should stay in the kernel. So the idea of moving much of the early boot process into initramfs might not get very far.
Fears were expressed that, by putting more of the kernel into a user-space initramfs area, the developers could create a situation where users are tied to their distributor's kernel. There is a strong desire to ensure that mainline kernels continue to work on as many distributions as possible.
One question which comes up occasionally is whether code which is tightly coupled to the kernel should be packaged with the kernel. A common example is udev, which has been broken by a kernel release at least once. If tools like udev lived with the kernel, the tools and the kernel could be updated together and version skew problems would not develop. There is some sympathy toward this idea, but no immediate plans to add any tools to the kernel source tree.
When such plans are made, kernel crash dump tools might be at the top of the list. Another possibility is the hal program used by the GNOME and KDE desktops. It was described as "unmaintained crap" which is heavily depended upon by the desktop environments. The kernel developers, it was suggested, should help to get hal onto a better footing, possibly by bringing it into the kernel source tree.
| Index entries for this article | |
|---|---|
| Kernel | klibc |
| Kernel | User-space API |