Keeping up with the Kroah-Hartmans (who upgrade without notice)

Keeping up with the Kroah-Hartmans (who upgrade without notice)

Would Andrew Morton be complaining if a userspace program broke that
depended on the layout of kernel objects in /dev/kmem? The whole point
of /sys (as opposed to the now-somewhat-deprecated /proc) is that it
reflects internal kernel data structures. Which are subject to change
without notice, according policy which has been stated most vociferously
by Greg K-H himself.

This means that Linus' policy against messing with userspace interfaces
cannot meaningfully apply to sysfs, any more than to kmem. But since
sysfs has only a couple of meaningful userspace clients, namely the HAL
library and the udev daemon, which are updated more-or-less in parallel
with the kernel, the stable interface boundary moves to the library API
and the 'far side' of the daemon: its configuration files and the device
nodes created in /dev are what must remain consistent.

Whether or not udev and HAL are maintained as part of the kernel source
tree (as recently proposed), the solution to this problem is simple: if
you want to run a new kernel, update userspace packages that depend on
kernel internals correspondingly. More recent udev daemons ought to
continue to understand older kernels, so users need only keep the latest
one on their systems: this is the right place for translations as
proposed by a sibling post. But the converse obligation, that the latest
kernel should support old versions of udev and HAL, imposes *exactly* the
'stable API nonsense' that the kernel developers have declared utterly
unacceptable.

The same issue has come up before -- eg. with insmod -- and the solution
has often been not only to pull the implementation into the kernel tree
so it can be maintained properly, but actually to do the work in
kernelspace, despite an earlier preference that it be done by a user
process. I suspect there are several other pieces of code which might be
better implemented as userspace utilities maintained alongside the
kernel, rather than *inside* it.

> There are limits, however, to how many tools can be packaged
> in this way

What limit, exactly, is there on userspace packages maintained in sync
with the kernel tree? The kernel tree is already huge and growing
rapidly. The advocated solution for any project (usually an out-of-tree
driver) which begs for a stable kernel API is to bring it in-tree. Why
should that rule be any different for those userspace tools that are
necessarily coupled to kernel internals? They're usually maintained by
kernel developers anyway; wouldn't it smooth the workflow to have it all
in the same place?

Projects such as KDE and GNOME manage to maintain numerous libraries and
applications in a combined source tree and to release them together. I
can't see why AM thinks people running Fedora Core 3 should want to
upgrade to an arbitrarily recent kernel without also updating a couple of
dependencies. Does he likewise think the users should be able to upgrade
GNOME without updating any supporting packages?

The bottom line is that sysfs is a window into the interior of the
kernel, which maintains the right to change without notice. Userspace in
general cannot depend on it. udev and HAL *are* the interface and
therefore must remain current with the kernel.