ABI stability documentation [LWN.net]

Last week's Kernel Page looked at the stability of the user-space interface, especially regarding areas like sysfs, which are not always regarded as being part of the kernel ABI. This week, Greg Kroah-Hartman has made an attempt to make the issue more evident through a set of ABI stability documents. Included in his patch is a proposal for a different way of looking at ABI stability issues.

Linus has, in the recent past, taken a hard line on changes interfaces to user-space:

If you cannot maintain a stable kernel interface, then you damn well should not send your patches in for inclusion in the standard kernel. Keep your own "HAL-unstable" kernel and ask people to test it there.

It really is that easy. Once a system call or other kernel interface goes into the standard kernel, it stays that way. It doesn't get switched around to break user space.

Greg, has, instead, taken the approach that not all kernel interfaces should be seen as stable from the outset. So he has proposed five different classifications for ABI stability:

Stable. Interfaces classified as stable will not break "for at least two years," and probably quite a bit longer. The Linux system call interface is classified in this way.
Testing. A "testing" interface is one which has been through most of the development process. It is not expected to change, but, that notwithstanding, the possibility of an incompatible change before the interface becomes "stable" does exist. This is the time for user-space programs to begin to make real use of the interface, but user-space developers need to pay attention to what is happening on the kernel side. The sysfs files under /sys/class have been designated as having a "testing" level of stability by Greg's documentation.
Unstable. This classification is for relatively new interfaces which are expected to change as problems in the initial implementation become clear. Sysfs files under /sys/devices are classified as "unstable."
Private. This class describes interfaces which are intended to be hidden behind a user-space library and which should not be used directly by applications. The ALSA sound system is an example of a "private" interface.
Obsolete marks interfaces which are destined to be removed, and which should not be used at all. Few long-timer observers will be surprised to see that Greg marked devfs as being obsolete.

Linus doesn't like the unstable and private classifications, calling them "excuses for bad habits." But it is true that inclusion in the mainline can stress an interface in surprising ways, leading to a need for changes. Interface design is hard, even if you don't have to get everything right the first time. So it may make some sense to allow unstable interfaces into the kernel for a short while - as long as they are clearly documented as such. Thus far, there has been no way to warn developers that a certain interface, perhaps, shouldn't be relied upon quite yet.

The notion of private interfaces looks harder to justify. There has been some talk of shipping user-space libraries for private interfaces with the kernel, just to help ensure that the whole package provides a stable application interface for any release. That seems like a fairly unlikely change, however, at least for big interfaces like ALSA.

Changes will likely be made (this scheme might be classified "unstable" at this point), but it seems probable that it will, in some form, be adopted. That can only be a good thing for people interested in a stable user-space interface; once the expectations have been reasonably well documented, it will be easier to live up to them.

(Log in to post comments)

Private interfaces

Posted Mar 9, 2006 15:20 UTC (Thu) by forthy (guest, #1525) [Link]

Sometimes, it's wise to split up a function between kernel and user space, think for example the TCP in userspace experiment. The kernel quickly pushing packets to the userspace TCP library allows a much faster implementation than a in-kernel TCP stack, and at the same time, development gets easier (most of the stuff is in user space, anyway). These splits need a kernel interface, but there's no point to encourage usage of this interface. The application should use TCP, not the weird kernel interface.

So in these cases, the kernel boundary is not an interface, but just an arbitrary boundary in one program that exists on both sides (in the user space library and in the kernel). This is a micro-kernel view of things, because in a micro-kernel world, no application programmer in his right mind would use the micro-kernel functionality directly, but user-space libraries. Linus might not like micro-kernels, but it has been demonstrated that micro-kernel-like approaches can make parts of the kernel faster. In this case, the "private" interface is not bad practice.