utility has a well-defined job: take information from
kernel events and the sysfs virtual filesystem and use it to create device
files corresponding to the actual configuration of the system. If
falls down, the system will be partially or completely
unusable, a situation which tends to go over poorly with users. So, when
Andrew James Wade reported
failure with a recent -mm kernel, the developers took notice.
The problem, as it turns out, is caused by some sysfs changes designed to
improve power management in the kernel. The immediate problem can be fixed
by adding another patch, but that, in turn, only leads to further problems;
a number of distributions will break because the version of udev
they ship is too old to understand the new sysfs format. Andrew Morton complained that Fedora Core 3 breaks, but
the problem is likely to be more widespread than that.
Greg Kroah-Hartman, the developer behind the changes, responded this way:
That distro is unsupported now, right?
How long do you expect the kernel to support unsupported, community
based distros that thrive on the fact that they are quickly
And yes, I will revert the patch in mainline that causes people to
have to upgrade to a udev that is in FC5, and wait till the next
release for that to happen (the minimum will be 081, which was
released in January, 2006, by the time 2.6.19 is out, that will be
about 10 months old.)
Andrew was unimpressed:
My (repeat) point is that we're proposing to break _all_ distros
which are older than ten months. We don't play the "oh, that isn't
supported any more" game....
This sucks. Do you know what machines we'll be breaking out there?
I sure don't.
Among others, distributions scheduled to break with the 2.6.19 kernel
include Ubuntu 6.06 LTS ("dapper") and the not-yet-released Slackware 11.
So, unsurprisingly, it's not just Andrew who is displeased by this change; there is
a definite chance that the whole set of patches will be withdrawn and
Greg asks a fundamental question, however:
"How long should the community have to care about a distro after the
creators of it have abandoned it?" The traditional answer has been
"forever," but the new generation of "kernel in user space" tools is making
that promise harder to keep. Tools like udev are tightly tied to
the sysfs filesystem which, in turn, is a nearly direct representation of internal
kernel data structures. Sysfs functions, in some ways, like an internal
kernel API, but it is, in reality, a user-space interface. Keeping it
stable and avoiding compatibility problems with older user-space tools is a
difficult challenge, aggravated by the fact that the kernel developers are
still well within the process of figuring out how sysfs should really work.
At this year's Kernel Summit,
there was some talk of folding tools like
udev into the kernel code base and distributing them together.
New kernels would always come with a version of udev that worked,
and some of these compatibility problems would go away. There are limits,
however, to how many tools can be packaged in this way, and, in any case,
it can be hard to see this approach as anything other than a hack to avoid
the hard problem of keeping such a wide and complex ABI stable.
This particular problem will likely be worked around, one way or another.
But it won't be the last such. If the kernel developers are going to
continue to promise that the user-space ABI will remain stable
indefinitely, they will have to get a handle on all aspects of that ABI -
not just the system calls. It will not be easy: modern systems require
complex communications between the user and kernel realms. But the kernel
developers have solved plenty of "not easy" problems so far; given the
increased attention being paid to ABI regressions, they will probably
figure this one out too.
to post comments)