The current development kernel is 2.5.33
, which was announced
by Linus on August 31.
Among other things, this
kernel includes support for the SCTP protocol, offloading of TCP
segmentation into network cards (see below), some IDE work, more memory
management and file I/O improvements from Andrew Morton, more input driver
work, and, perhaps, a floppy driver that actually works. The long format changelog
is also available.
As of this writing, Linus's BitKeeper tree includes the removal of
list_t (once again, see below), a number of memory management
changes from Andrew Morton (including the NUMA discontiguous memory patch),
more floppy driver fixes, and a number of other fixes and updates.
The current 2.5 Status Summary from Guillaume
Boissiere came out on September 4.
The current stable kernel is 2.4.19. Marcelo released 2.4.20-pre5 on August 28; it includes a
long list of fixes and a big merge from Alan Cox.
Speaking of Alan, he released 2.4.20-pre5-ac2
on September 4. It includes a number of fixes and a small bit of IDE
work, but this prepatch was aimed more at stabilizing things than adding
Alan has also released 2.2.22-rc2. It
contains more fixes than one might expect for a release candidate; among
other things, it contains some worthwhile security fixes.
Comments (none posted)
Kernel development news
The direction of Linux IDE development - now that most of the work
previously done for 2.5 had been thrown out - is becoming a little
clearer. Andre Hedrick has posted a 2.5 IDE
, his first in many months. Along with the patch, Andre states:
We are back. We is a development team being composed to reduce my
load and import fresh ideas. If you wnat to help please join in,
we can make the halloween party.
The initial 2.5 patch consists mostly of relatively small cleanups, but
Andre tells us that much more ambitious changes are in the works.
Actually, much of the relevant work has already been done for the 2.4 (or
2.4-ac) series, and the rest, should Alan Cox and Marcelo Tosatti be
willing, should go in soon. This work includes complete support for memory
mapped ATA controllers, which is a precondition for serial ATA support
(which is also on the list); fixes for a number of Promise controller
issues; support for split-channel operations; and a tagged command queueing
implementation which, says Andre, avoids some potential problems found in Jens
Axboe's version. Additional work envisioned for 2.5 includes a
standardization of the ATAPI layer and automatic loading of subdrivers.
The auto-loading feature is aimed at the classic CD burner problem: regular
tasks are handled as standard ATAPI operations, but burning a disk requires
loading the IDE-SCSI module. Andre's plan is to have the IDE layer select
the appropriate subdriver based on which device the user-space application
opened, making this switch be automatic and transparent.
That, of course, is a long list of changes to get into the kernel in less
than two months. To that end, Andre has recruited help from a number of
directions. Alexander Viro is "the BUZZIT guy" helping to improve code
quality, as well as continuing his work on things like partition table
handling. Bartlomiej Zolnierkiewicz has his hands in the code, as do a
number of other people. And all the changes, of course, must pass Alan
Cox's inspection on their way into the 2.4-ac tree. Alan has already demonstrated that he will not take IDE patches
that don't pass muster, and Andre seems to be doing his best to rework the
Things, thus, seem to be off to an encouraging start. The list remains
long, however, and the deadline is close. And Linus hasn't looked at the
code yet. The IDE work is going to have to proceed quickly to get that
Comments (none posted)
Most people who dig through the kernel source eventually run into
, the structure used for the management of
generic, doubly-linked lists in the kernel. The kernel list implementation
has some interesting features, including the fact that every entry in the
list is a "list head." The lists are circular, and no one node is special.
Recently, a typedef (list_t) was added as an equivalent name for
the list_head structure; rumor has it Ingo Molnar added the name
to help keep his source lines within 80 columns. One would think that
people would not get overly worked up about this addition, but this
is the kernel hacker community we are dealing with. The prevailing
opinion among kernel hackers has swung strongly against typedef in
recent times. Use of typedef is seen as a useless hiding of
information that programmers need to see. Defined types also complicate
include file dependencies. Structures can be "predeclared" with a line
and references to that structure (pointers, in particular) can be used as
long as the internals of the structure are not accessed. Defined types can
not be predeclared in this way, making it harder to mix mutually-dependent
types across files.
So Rusty Russell posted a patch which removes
list_t from the kernel. Nobody really complained about that
change, but some wondered: why not rename the list_head structure
to struct list at the same time. As William Irwin rather
graphicly put it: "Throw the whole frog
in the blender, please, not just half."
In the end, a big renaming of struct list_head throughout the
kernel tree (and external code) wasn't to most peoples' taste. And Linus
isn't into blended frogs. So the patch
removing list_t went into Linus's BitKeeper tree (and will be in
2.5.34), but struct list_head remains.
Comments (2 posted)
One of the many tasks performed by the networking stack is TCP segmentation
- turning a large chunk of data sent by an application into a series of
packets small enough to fit within the maximum transfer size. The
segmentation task involves performing checksums, making headers to match
each segment, perhaps copying the data to assemble the packet, and
transfering that packet to the network controller. This work is a
significant part of the overhead of sending data over a network.
Some modern controllers, though, have the ability to do segmentation
internally. In this case, the operating system passes in a set of template
headers and a single, large chunk of data; the adaptor handles the rest.
Much of the segmentation work goes away, and a number of smaller I/O
operations turn into one big, fast transfer.
As of 2.5.33, the Linux kernel understands segmentation offloading, and the
e1000 driver supports it; the work was done mostly by Alexey Kuznetsov and
Chris Leech. Some results posted by Scott
Feldman show what this change buys. In general, transfers do not go any
faster, for a simple reason: the Linux network stack was already able to
drive the interface at the speed of the wire. On a send of a long file,
however, CPU usage dropped from 40% to 19%. This seems like an
optimization worth having.
Comments (2 posted)
Larry Augustin has sent out notice that Leonard Zubkoff, a longtime Linux
kernel hacker and former CTO of VA Linux Systems, was killed in a
helicopter crash in Alaska. Leonard was the source of many contributions
to the Linux community, as well as being a generally nice person; he will
be greatly missed.
Full Story (comments: 3)
Patches and updates
Core kernel code
Filesystems and block I/O
Page editor: Jonathan Corbet
Next page: Distributions>>