The current development kernel is 2.6.0
(we're not quite ready to
call it a fully stable kernel yet). This kernel was released
by Linus on December 17, right
after last week's LWN Weekly Edition went out saying it hadn't been
released. Linus, we think, does this on purpose. Anyway, this kernel
contains a small number of very small patches; see the long-format changelog
for the details.
As of this writing, there are no patches in Linus's BitKeeper repository.
The current stable kernel is 2.4.23; Marcelo released the second 2.4.24 prepatch on
December 22. This prepatch adds some ACPI fixes, various driver
updates, an XFS update, and various other fixes.
Comments (4 posted)
Kernel development news
Linus and Andrew have, at long last, released the 2.6.0 kernel. What
If you are a potential user of the new kernel, and you have not worked with
2.5-series development kernels thus far, there are some resources to
- Dave Jones's Post-Halloween
document, which has been updated to 2.6.0. Here you'll find an
extensive description of what has changed, what issues remain, and
what tools you may have to update to run this kernel.
- Joe Pranevich's Wonderful
World of Linux 2.6 continues his tradition of documenting the
features available in the new stable kernel.
- Andrew Morton's notes on what to expect
from 2.6.0 are also worth a read.
If you are a developer looking to update out-of-tree code to the new kernel
(and there seem to be quite a few people answering to that description out
there), we humbly recommend the LWN.net
Driver Porting Series. It answers a number of questions which have
been posted to linux-kernel recently.
Where do things go from here? As Linus pointed out in the 2.6.0 announcement, Andrew Morton is now
the maintainer for 2.6. This is the first time that Linus has passed off
responsibility for the stable series before moving on to the new
development tree. So the most likely place to look for patches likely to
go into 2.6.1 (and subsequent kernels) is Andrew's -mm tree, currently at
2.6.0-mm1. That tree contains an impressive
384 patches, some of which are significant. There are also quite a few
patches in the hands of their respective developers which will surface as
soon as it appears they might go in.
Looking at all of these patches can be a little discouraging; it is easy to
envision a 2.6.x kernel which, after a big patching frenzy, is rather less
stable than 2.6.0. Certainly things have worked that way with some
previous stable kernel releases. There is cause for optimism, however.
Andrew has a strong interest in keeping the stable kernel truly stable, and
many of the patches in -mm have been there for quite some time. Not all of
the -mm patches will go into 2.6, but those which do will have already been
put through their paces by users of the -mm tree.
The question of more interest to many developers is: when will the 2.7 tree
open up? The stabilization period between 1.0 and 1.1 was all of 34 days.
With 1.2, however, things began to stretch out; it took 97 days before 1.3
started. Developers waited 113 days for 2.1 and 105 days for 2.3. The
delay between 2.4.0 and 2.5.0 was the most stressful of all for kernel
hackers; it took a full 323 days. There is reason to hope that the wait
for 2.7 will not be anywhere near as long; 2.6.0 is in better shape than
2.4.0 was. But it would be surprising if the stabilization period were
shorter than it has been for other 2.x releases. So we can expect to wait
at least three months, putting the beginning of 2.7 sometime in March,
2004 or thereafter. But that, of course, is just a guess.
Comments (1 posted)
Unix systems, and their variants, provide a number of ways for processes to
manage multiple I/O streams simultaneously. One of those is through the
use of I/O signals; a process can request to receive a SIGIO
whenever a given file descriptor becomes available for reading or writing.
Inside the kernel, this signalling is handled via a file-specific
structure and a couple of helper functions. One of
them, called fasync_helper()
, simply helps the kernel (filesystem
or driver) code track which processes have requested notification for a
given file. The other, kill_fasync()
, is invoked to actually
deliver a signal to interested processes when the time comes.
The kernel uses a single reader/writer spinlock (fasync_lock) to
serialize all calls to either helper function. In some situations, it
would seem that this lock is starting to hurt performance. It seems that
more types of
devices support I/O signalling than was once the case, and the increasing
number of calls to kill_fasync() is creating lock contention. So
did something about it, in the form of a
patch which switches the I/O signalling code over to the read-copy-update
mechanism for mutual exclusion. The result for his particular test load
was an 80% reduction in the time required to send out I/O signals.
Linus, having issues with how some of the locking was done, didn't much
like the patch, But he also had some ideas
for reworking the whole I/O signal mechanism to get rid of a lot of
The key is in the understanding that the list of processes wanting I/O
signals is very similar to the list of processes simply waiting for the I/O
itself. Either way, it is a list of processes that needs to be notified
when data becomes available or the file descriptor becomes writable. There
is not a whole lot of difference between sending a SIGIO to the
process and simply waking it up.
During the 2.5 development process, the wait queue mechanism was
generalized somewhat; this Driver Porting Series
article describes some of the changes which were made. The kernel
function wake_up() (with several variants) is called to wake
processes which are waiting on a wait queue; in 2.4 and prior kernels, it
performed that wakeup directly. In 2.5, however, all wake_up()
really does is call a special wakeup function, a pointer to which is stored
in the wait queue entry. This indirection allows different processes to be
awakened in different ways.
So far, there are few cases where a non-default wakeup function is used.
But there is no real reason why, with a suitable wakeup function, wait
queues could not be used for any of a number of different process
signalling tasks. The whole I/O signalling mechanism and its
fasync_struct structure could really be replaced by a wait queue
with a special wakeup function.
The only problem with this nice, elegant idea is that it won't work.
kill_fasync() takes a "band" argument which eventually gets passed
though to the target process as signal data. There is currently no way to
pass that information to a wakeup function via wake_up(). Adding
a data parameter to wake_up() would fix that problem and, perhaps,
enable a number of other potential uses for wait queues. Such a change
appears likely to happen - but not until 2.7. Such changes really
shouldn't be made in 2.6, now that the 2.6.0 kernel has come out.
Comments (1 posted)
A kernel developer recently asked
code implementing an algorithm known to be patented be submitted for
incorporation into the Linux kernel? Given that Linus has promoted
an approach to software patents in the
past that some see as being a bit cavalier, one might be forgiven for not
knowing the answer in advance. But Linus's
was clear: "Don't submit, and find an unencumbered
The two points of view expressed by Linus are entirely compatible. Code
which is known to have patent encumbrances cannot go into the kernel,
because such inclusion is (or could lead to) a knowing act of
infringement. On the other hand, kernel developers should not go out of
their way looking for potential patent problems with their code. That way
lies madness -- there's no end of bogus software patents out there. Known
problems should be kept out of the kernel; the rest should not be worried
about until something comes up.
That said, a couple of interesting points were raised in the discussion.
One is that the exclusion of patented code hurts all users of the kernel,
even though many of them (a majority, even) are, for now at least, in
jurisdictions which do not recognize the patents in question. Rather than
exclude code with patent encumbrances, why not create a configuration option making the code
available to those who can legally use it? The burden would then be on the
end users to think about what they can do before explicitly turning on an
option which would enable patented code.
Various objections can be raised to this scheme, of course. It would turn
our free kernel into a partially proprietary system, at least in some
countries. Patents are public knowledge, so publishing an implementation
should not be a problem as long as the patented code is not used in places
where the patent is recognized. But somebody might still try to file a
suit complaining that the kernel (and its developers) are contributing to
an infringement. The community also does not need another reason for
certain critics to proclaim that Linux is putting its end users into legal
danger. For all these reasons, the inclusion of patented code with a
configuration option seems unlikely.
There is one other potential issue, however; as Jamie Lokier pointed out, there is already some code in the
kernel with patent issues. There is a
documentation file in the kernel source which discusses the SB-Live
mixer code - and patents which may cover it. If there is a license which
allows those patents to be used in the kernel, the file fails to mention
it. The kernel also contains a "flash translation layer" memory card
driver; the FTL format it implements is subject to a patent owned by M-Systems. The
license that goes with that code allows the use of the patented technology
- but only with PCMCIA cards. The covered code is, thus, not entirely
Given the nature of the software patent regime (especially in the U.S.), it
seems certain that more patent-encumbered code will be found in the
future. It would not be surprising if, one day, we were faced with a
patent covering an important piece of code in a heavily-used kernel
subsystem. At that point, some difficult choices will need to be made.
Until then, however, there is little to be done.
Comments (11 posted)
Patches and updates
- Andrew Morton: 2.6.0-mm1.
(December 23, 2003)
Core kernel code
Filesystems and block I/O
Page editor: Jonathan Corbet
Next page: Distributions>>