The current development kernel is 2.6.0-test11
, otherwise known as
"Beaver in Detox," which was released
Linus on November 26. This release contains a very small number of
important fixes; the long-format changelog
has the details.
The -test11 announcements says "And after that it will be up
to Andrew to say how to go on from here." Even so, Linus's
BitKeeper tree contains a handful of other patches which, presumably, will
find their way into a release at some point.
The current stable kernel is 2.4.23, which was released by Marcelo on November 28. No
changes were made between -rc5 and the final release.
Comments (none posted)
Kernel development news
The first test release for RTAI 3.0 is now available. RTAI is an extensive
set of real-time extensions for the Linux kernel; this release includes a
great many improvements, which are described in the announcement.
Full Story (comments: none)
The Advanced Linux Sound Architecture (ALSA) project has been
working at the creation of a new audio subsystem
for the Linux kernel (along with user-space support) since
early 1998. Now, almost six years later, the project has announced
its first 1.0 release candidate.
This release is not that far removed from what is in the 2.6.0-test11
kernel; still, it might be a good time for audio enthusiasts to test things
out one last time.
Comments (1 posted)
After the 2.4.23 release, maintainer Marcelo Tosatti let it be known
that the development period for
the 2.4 series is coming to an end. His plans are to accept relatively
intrusive patches for 2.4.24 - especially driver patches. But, starting
with 2.4.25, only serious bug fixes will be accepted. People will be
running 2.4 kernels for some time yet, but the 2.4 series will not be
acquiring new features.
The result of this sort of announcement is always predictable: people start
coming forward with the the patches that they feel, for whatever reason,
absolutely have to be merged before the gate closes. One of those
is Jeff Garzik's "libata" driver, which provides much improved serial ATA
support. Marcelo initially said that he would incorporate libata, but has
since changed his mind, saying that people
who want libata should use 2.6.
The big discussion, however, concerned the inclusion of the XFS
filesystem. XFS is relatively controversial because it requires some
significant core VFS changes, and not everybody is happy with the quality
of the code. There was enough clamor, however, that Marcelo has relented
to the extent that, if some of the core filesystem maintainers can be made
to agree, he will let XFS in.
The reasoning behind the policy change for 2.4 is that the 2.6
kernel is on the horizon. 2.6.0 may well be released before a 2.4.24
kernel could be prepared. At that point, attention is expected to shift to
2.6, and there won't be much interest in 2.4 anymore. This approach does
worry some people who remember that the 2.4 kernel took almost a year to
truly stabilize after 2.4.0 came out. If 2.6 follows the same path, Linux
users could be left for several months with no kernel which is being
updated with new drivers, bug fixes, etc.
The general expectation, however, is that the early part of the 2.6.x
series will be rather more successful than 2.4 was. The 2.6.0-test kernels
seem to be far more stable than 2.4 was at this stage, and there is a high
level of confidence in Andrew Morton's willingness and ability to stabilize
things further. Not everybody realizes how differently the development
process is working this time around. The year-old feature freeze has
(mostly) held, which is a nice difference. But the big change is that
Linus will be handing 2.6.0 to Andrew Morton from the beginning. In the
past, Linus has always continued to manage the stable kernel releases until
he felt confident in moving on to the next development series. Linus, by
his own admission, is not the best release manager for a stable kernel; he
would much rather be breaking things. So his early handoff of 2.6 could
make a big difference in how quickly that kernel becomes truly usable.
That said, 2.6.0 is still not going to be the best kernel to use to run
your nuclear power plant. A small set of fixup releases will certainly be
required first. But the confidence in 2.6 is high enough that the
distributors are looking in that direction for their future releases.
There is little interest in building a new distribution release on 2.4;
that, more than anything else, is the reason for putting 2.4 into a
"critical fixes only" mode in the near future.
Comments (4 posted)
The Linux developers have long, and with reason, been pleased with
the performance of the kernel's networking subsystem. For various
, there is also a longstanding rivalry between the Linux
networking hackers and their Sun counterparts. So when The Register posted
about the "Fire Engine" networking stack which will be part of future
Solaris releases, it drew some attention. This quote from John Fowler,
Sun's software CTO:
Also we focused on CPU utilization. One of the little secrets of
networking is high speed interfaces can in fact pump lots of bits,
but they chew up lots of CPU, which means you aren't doing other
things. We worked hard on efficiency, and we now measure, at a
given network workload on identical x86 hardware, we use 30 percent
less CPU than Linux.
also didn't help.
The dissection of Sun's claim was quick to begin. It was pointed out that
we don't know which version of Linux is being referred to in the quote.
There's a lot of differences between the 2.4 and 2.6 kernels, and it would
not be quite sporting for Sun to be comparing its upcoming, unreleased
technology with an old version of Linux.
Sun's performance improvements appear to be based on the use of "TCP
Offload Engine" (TOE) technology. The idea of a network adaptor which can
take on the network protocol overhead is not particularly new; such
hardware has been available for many years. The Linux networking hackers
have always had a low opinion of the TOE approach, however. TOE hardware
may offload a bit of work from the processor, but it suffers from a number
- When you use TOE hardware, you have just moved your networking
stack into a firmware-based, close-source module. This code can not
be inspected, fixed, or improved.
- TOE-based networking suffers from latency problems. The setup and
teardown of network connections still requires the processor's
intervention, and that means several round trips over the bus for each
- As Larry McVoy heard from "Sun employee
#1," processors are getting faster much more quickly than TOE hardware
is. Even if a TOE adaptor performs reasonably when it is released, it
will be quickly outstripped by processor-based TCP implementations.
The 2.6 networking stack is happy to offload some functions to smart
interfaces; examples include packet checksumming and TCP segmentation. But
the full TCP offload approach is likely to remain unpopular into the
In general, the networking hackers do not feel threatened by "Fire Engine."
That didn't stop them from having a discussion of how Linux networking
could be made faster, however. The conversation was based around a shopping list of possible improvements posted
by Andi Kleen. This list includes a number of good ideas, but the bulk of
the debate concerned a relatively obscure topic: timestamp generation.
Certain applications want to get each packet packaged with a timestamp
saying exactly when that packet was received. Tools like tcpdump, for
example, make use of this capability. The socket interfaces were designed
in such a way that the networking subsystem cannot know if any particular
packet needs to be timestamped or not; as a result, it generates timestamps
for all incoming packets, even though they are rarely used.
The problem is that this timestamp generation gets to be expensive when you
have thousands of packets flowing through the system every second.
Depending on the architecture Linux is running on, generating the timestamp
can involve talking to a (slow) off-CPU timer or moving cache lines
frequently between processors. Improving the timestamp generation might be
the most straightforward way of speeding up Linux networking, at least at
the high end.
That fix is not entirely easy, however. Networking maintainer David Miller
is unwilling to make any changes that would reduce the accuracy of the
timestamps returned to user space. Any such changes would be seen as an
API change; somebody, somewhere, would be badly affected by it.
The proper solution, as proposed by David,
is the creation of a new fast_timestamp_t type which is quicker to
generate, but which can be converted to a real time when the need arises.
The optimal implementation of this type would be highly dependent on the
underlying architecture; on many systems the CPU cycle timer could be used,
but that approach would not work universally. A default,
architecture-independent "fast timestamp" implementation is easy to add,
however. Creating that sort of structure for the architecture maintainers
to play with may be one of the first things to happen when the 2.7 series
Comments (4 posted)
Patches and updates
Core kernel code
Filesystems and block I/O
Page editor: Jonathan Corbet
Next page: Distributions>>