The current development kernel remains 2.6.0-test11
; Linus seems to
be waiting for Andrew Morton to return from vacation and pick up the
baton. Linus has, however, accepted a few dozen small bugfixes into his
The current stable kernel is 2.4.23; Marcelo has started off the
2.4.24 process with 2.4.24-pre1. This
prepatch includes the XFS filesystem (see below) along with a fair number
of networking and architecture patches.
Comments (1 posted)
Kernel development news
As reported last week, many users had requested that the XFS filesystem be
added to the 2.4 kernel despite Marcelo's stated intent to go into a
maintenance-only mode. Those users have prevailed: Marcelo has announced
that, after a review by Christoph
Hellwig, XFS has been merged into his 2.4 tree. It will thus show up in
the first 2.4.24 prepatch, whenever that is released.
What has gone into 2.4 is, in fact, not the full XFS patch. Two subsystems
have been left out:
- DMAPI (Data Management API). This is an interface which allows the
filesystem to communicate with hierarchical storage management
- ACLs. Access control lists require more general extended attribute
support, which has never been merged into 2.4.
Users needing those features in XFS will have to run 2.6 to get them. Most
users, however, will most likely be happy with the core XFS filesystem.
Meanwhile, a new request has been heard: could the device mapper (LVM2)
code be merged? Marcelo's answer was
direct: "I believe 2.6 is the right place for the device
mapper." That would seem to be the end of the matter, but arguments
are now being marshalled to try to get Marcelo to change his mind. This posting by Kevin Corry covers the relevant
points quite well:
- LVM2 is a lot nicer. The user-space tools, many taken from IBM's
EVMS project, are easier to work with, and the device mapper code
provides many capabilities that simply are unavailable in LVM1.
- LVM1 itself has been removed from the 2.6 kernel (though LVM2 does
provide backward compatibility). Putting LVM2 into
2.4 would make the transition easier for LVM users; they could get
their volume sets working with LVM2 before having to commit to the new
The forward compatibility argument strikes a chord with many participants
in the discussion, but Marcelo is, for now, adamant. One never knows, though; he
previously has taken equally strong positions against ACPI and, of course,
XFS, but been won over in the end.
Comments (7 posted)
Some of the new users who are just now beginning to test out the 2.6 kernel
are encountering a bit of a surprise: devfs is now marked as being
deprecated, and users are being pointed to the user-space "udev" solution
instead. The deprecation of devfs is no surprise to those who have been
following the discussions; despite significant fixups over the 2.5
development cycle, the devfs code continues to have problems which are seen
as not being fixable. Some of these problems can lead to kernel deadlocks
and worse. These issues are compounded by the fact that the devfs
maintainer, Richard Gooch, has not been heard from in some time.
The loss of devfs bothers a relatively small number of people; of the large
distributions, only Gentoo uses devfs. But those users have tended to be a
little unhappy with the alternatives - many people who have looked at udev
(which was first examined here back in
April) have concluded that it is not yet ready. Many of the features
of devfs are still missing, udev does not yet handle all types of devices,
and support for the devfs naming scheme has been slow in coming. As a
result, devfs users feel left out in the cold.
What some observers may have missed is that udev development has taken off
in the last couple of months. udev 003,
released on October 16, was mostly the work of its original author,
Greg Kroah-Hartman. Since then udev has picked up its own development
community and evolved considerably. The current release as of this writing
(udev 008) is a much stronger offering, and
several new features are queued up for the 009 release as well. Among
other things, udev now offers:
- A FAQ
file of its own.
- A "callout" option which allows difficult devices to be set up with an
- Ability to build with klibc for embedded or initramfs usage.
- Proper disk partition support.
- Printf-style formatted dynamic name support.
- Regular expression pattern matching in rules.
- Symbolic link support.
...and quite a bit more. At this point, udev contains something close to
the full set of features needed to enable it to replace devfs.
The problem is not yet entirely solved, however. udev depends on sysfs for
the information needed to configure device nodes, and not all devices have
complete sysfs support at this point. Thus, for example, udev will not yet
work with input devices, misc devices, and some others. Certain kinds of
subtleties (distinguishing CDROM drives from regular disks, for example)
are not yet there. The fault is not with udev itself, but with the
information (or lack thereof) that it gets from the kernel. In many cases,
patches to add the relevant devices to sysfs are in circulation, but have
not yet been merged into 2.6. Once that support has been added, the
picture will be nearly complete.
There is one remaining question from devfs users, however, which has earned
its own place in the FAQ: dynamic loading of drivers. devfs has the
capability to create a device node while deferring loading of the
appropriate driver module until a user program actually opens that device
node. udev cannot do that, and there is no plan to add that support. In
the 2.6 world, driver modules are loaded by the hotplug mechanism when the
device is detected, so there is no need to load them at open time. This
approach bothers some users who prefer not to load drivers for rarely-used
devices, but most users will be able to live with it.
(See also: the udev 008 man page for
information on how udev works, and
Robert Love's HOWTO on using udev
with the development version of Fedora).
Comments (8 posted)
This week's Front Page contains an interview
with a lawyer on the issue of what makes one program a derived work of
another. That topic has also been prominent on the linux-kernel mailing
list recently as part of the never-ending debate over the status of
closed-source kernel modules. Unusually, Linus Torvalds has taken an
active part in the discussion this time around. Linus does not have the
last word on this issue - his copyrights only cover a small part of the
kernel code base - but his thoughts are influential in this regard and can
be taken as a sort of guidance for anybody who is considering distributing
a binary module.
It is reasonably widely accepted that a program which simply uses a
well-documented API does not become a derived work of the code implementing
that API. The obvious application of this principle is the kernel's system
call interface. That interface is an API (and ABI as well) which, to a great extent,
conforms to a well-documented standard, and which is meant to be stable
over time. The COPYING file supplied with the kernel explicitly states
that programs using the system call interface are not considered to be
derived works, but, according to Linus, that
statement is not strictly necessary:
In other words: even without that disclaimer of derivation, user
space would almost certainly (with a very high probability indeed)
be safe from a copyright infringement suit. Such a suit would most
likely be thrown out very early, exactly because the UNIX system
call interface is clearly extensively documented, and the Linux
implementation of it has strived to be a stable ABI for a long
Of course, there are differences of opinion. Thus, as Ted Ts'o points out, the FSF claims that users of the
readline library must be licensed under the GPL, even though there are two
BSD-licensed implementations of the same stable, well-documented API.
But let us accept, for the moment, that this sort of API does, in fact,
create a boundary for derived works. A fundamental question that some
developers have raised is: what is different about the interface used by
kernel modules? Several developers have argued that the module interface
is a boundary in just the same way as the system call interface. Linus's
response is that the module interface is,
But when you have the GPL, and you have documented for years and
years that it is NOT a stable API, and that it is NOT a boundary
for the license and that you do NOT get an automatic waiver when
you compile against this boundary, then things are different.
He go on to explain, in fairly graphic and non-technical terms, that the
stated intent of the interface matters, even if the technical steps
involved in using it are the same. The module interface is not a boundary because the
copyright holders never intended it to be one.
One can go further and say that the module interface is truly not an API in
the usual sense. It is, indeed, highly volatile, and has been known to
change even in the middle of a stable kernel series. The module interface
provides extensive access to low-level kernel functionality, often solely
for the convenience of other in-tree kernel code. Code which makes use of
many exported symbols is clearly Linux-specific. Some exported symbols are
so low-level that the kernel developers have concluded that no code can use
them without being a derived product; that is why
EXPORT_SYMBOL_GPL() exists. But, as Linus notes, EXPORT_SYMBOL_GPL() should be
seen as a form of documentation in specific cases; its existence does not
imply that modules restricting themselves to non-GPL-only symbols are
automatically not derived.
The crucial test, as seen by Linus, is whether a particular module was
implemented independently of Linux. Code ported from another system (such
as the Andrew filesystem) is a fairly obvious example. Device drivers are
generally seen as being independent as well.
Before going any further, though, distributors of closed-source modules
should consider one other thing that Linus
So in order for nVidia to be able to legally distribute a
binary-only kernel module, they have to be able to feel damn sure
that they can explain (in a court of law, if necessary) that the
module isn't a derived work. Enough to convince a judge. That's
really all that matters. Our blathering matters not at all.
Until a court makes a ruling, nobody really knows what the law really
says. Even then, as Dan Ravicher told us,
the ruling will only hold in the geographical area covered by that
particular court. There are no clear answers to this question.
The ambiguous legal state of closed-source modules may suit some developers
who want to discourage them strongly without trying to ban them outright.
But it is not beneficial for the Linux community as a whole. We
really do not need more messy court cases; we have better things to
do with our time and energy. As LWN has said before, it would be in the
community's interest to clarify the situation and make the boundary clear.
One possible step in that direction was suggested by Al Viro. He has pointed out in
the past that the module interface is a mess which could do with some
cleaning up. Now he suggests looking at who actually uses each exported
symbol and thinking about whether that symbol should really be made
available to modules or not. There are, as he points out, over 7500
EXPORT_SYMBOL() declarations in the 2.6 kernel; seemingly, only
about half of them are used by in-tree modules. A lot of these symbols, Al
suggests, could probably go away altogether. Others could be explicitly
exported only to certain modules with a clear need to use them - though the
mechanism to restrict exports in this manner does not yet exist.
An effort to clean up the list of exported symbols could, eventually, lead
to some clarity in the legal status of the users of those symbols. The
export list could be trimmed down to a point where most observers could see
it as a somewhat well-defined programming interface. At that point, maybe
most developers might be able to agree on a subset that binary-only modules
could safely use. The benefits of this agreement would be significant.
There would be one minor disadvantage in that the kernel developers would
have to find something else to argue about. One suspects that they are
probably up to the task, however.
Comments (9 posted)
Patches and updates
- Andrea Arcangeli: 2.4.23aa1.
(December 5, 2003)
Core kernel code
Page editor: Jonathan Corbet
Next page: Distributions>>