Kernel development

Kernel release status

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 new work.

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)

IDE development moves forward

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 patch, his first in many months. Along with the patch, Andre states:

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 patches accordingly.

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 halloween treat.

Comments (none posted)

Ending the list_t scourge

Most people who dig through the kernel source eventually run into struct list_head, 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 like:

    struct my_struct;

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)

TCP Segmentation Offloading

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)

Leonard Zubkoff killed in helicopter crash

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)