Kernel development

Kernel release status

The current development kernel is 2.5.50, which was released by Linus on November 27. Changes in this kernel include an ACPI update, lots of fixes from the -ac and -dj trees, some latency-reducing scheduling points, a Linux Security Module update, a big ISDN update, and a NEC v850 architecture update. The long-format changelog has all the details.

Linus's pre-2.5.51 BitKeeper tree includes a new, generic compatibility layer for providing 32-bit system calls on 64-bit systems, an XFS update, some performance improvements from the -mm patchset, lots of fixes from the -ac tree, a number of module fixes (see below), better SCSI disk hotplugging support, and numerous other fixes and updates.

The current stable kernel is 2.4.20, which was released by Marcelo on November 28. The 2.4.20 patch is large - 21MB - and it touches almost 3500 files. Even so, it is mostly dedicated to fixes and updates, and generally making the stable kernel even more so. Those looking for new features will not be entirely disappointed, however; 2.4.20 includes new e1000 and eepro100 drivers, the JFS journaling filesystem, the new wireless API, the "block I/O from high memory" patch, the BeOS filesystem, the NAPI high-performance networking code, a number of VM tweaks, and support for the x86-64 architecture. It also includes, of course, the fix for the recent x86 denial of service vulnerability.

Unfortunately, 2.4.20 also contains a bug which can corrupt ext3 filesystems mounted with the data=journal option. This bug is described in this posting by Andrew Morton (but the included fix does not work and should not be applied). A real fix for the problem is still forthcoming; until then, be careful with data=journal.

Alan Cox has released 2.4.20-ac1, which adds a few fixes and a PA-RISC update to the 2.4.20 release.

For 2.2 users, Alan Cox has released 2.2.23. It contains a number of fixes including, of course, the denial of service patch.

Comments (5 posted)

The state of 2.5 module support

As of 2.5.50, support for loadable modules in the kernel remains broken. As a result, there continues to be a low level of grumbling about the module changes, along with calls for their removal. Most developers seem to accept that the issues will eventually be worked out, however, and are meanwhile suffering in silence.

One problem that was the source of much complaining was the requirement that every module provide a module initialization function, or else include an explicit no_module_init line. This "feature" was set to force changes to large numbers of drivers, which were otherwise working just fine. The real purpose behind this requirement was to get the name of the module into the compiled code. Kai Germaschewski came up with a fix that allows the module name to be given at compile time; this fix was merged for 2.5.51.

A separate patch, also merged for 2.5.51, restores the generation of the USB and PCI hotplug tables.

Then, there is the little problem that module parameters do not work. Rusty Russell has been working on this issue for a while, and has produced several sets of patches, none of which have been merged as of this writing. The latest patch creates a new macro for the establishment of module parameters:

    module_param(name, type, perm);

Where name is the name of the local variable to receive the value given for the parameter, type is the type of the variable, and perm is a set of permissions flag that will be used in the future when parameters are exported via sysfs. module_param is slightly misnamed, in that it sets up parameters to be set at module load time, or, for compiled-in code, at boot time. But suggestions for other names (like simply "param") did not pass the Linus test.

There is also a compatibility layer which lets modules using the older MODULE_PARM declarations work until they are updated.

Finally, work continues on the new module tools (which may be found in this directory). These tools provide the usual module functionality, along with a script to convert the standard modules.conf file into the new modprobe.conf format.

Shaking out all of the module issues will doubtless take some time yet. But the worst problems are being solved; soon it will be time to find something else to complain about.

Comments (2 posted)

Making the DMA subsystem bus-independent

The Linux kernel has an elaborate set of support routines for performing DMA I/O operations. The DMA layer makes it possible to do high performance I/O without worrying (much) about the underlying, architecture-specific details. Some processors have cache-coherent memory (so that devices see data written from memory immediately), while others require explicit cache flushes. Some require the use of bounce buffers for some memory regions. Others can do nice scatter/gather operations through the use of bus mapping registers. By using the DMA layer (documented in the kernel source in DMA-mapping.txt and in Chapter 13 of Linux Device Drivers), driver writers need not worry about any of that stuff.

At least, they need not worry if their hardware is on a PCI bus. The DMA layer was written with broader applicability in mind, but the current implementation is PCI-specific.

James Bottomley has sent out a proposal to change all that. Why not, says James, fold the DMA code into the generic device model subsystem and make it more broadly available? The biggest part of his patch is concerned with renaming; the pci_* functions become dma_* instead, and they take a struct device argument, rather than struct pci_dev. The patch also includes some changes to make it easy for suitably-written drivers to fall back to inconsistent (non-cache-coherent) memory when consistent memory is not available.

As of this writing, there had been no public reaction to the proposal. The patch clearly heads in the direction the developers want to go, however, and it also includes the obligatory compatibility layer. One would assume that any objections would be based on details, and not the general idea.

Comments (none posted)

The OSDL Scalable Test Platform

The Open Source Development Lab has announced version 2.0 of its Scalable Test Platform (STP). STP is both a development project (available from SourceForge) and a service which has been made available to the kernel development community. Most developers are probably able to arrange for testing on their own systems, so the STP service is likely to be of the most interest.

Essentially, STP manages the building and testing of patched versions of the Linux kernel. The OSDL STP implementation has a set of systems which are available to do this testing. For now, at least, all of these systems are Intel-based; the largest box has eight processors and 8GB of memory. Interested developers can load their patches into STP, and select a system type of interest. When the hardware becomes available, a kernel is built with the developer's patches, and any of a set of tests are run; the results are then passed back to the developer.

The STP overview page suggests that STP testing can help get code accepted into the kernel. So far, there has not been a flood of developers using STP results to promote their patches. STP is, however, a useful tool that can help provide serious testing of patches on hardware that is not available to many developers.

Comments (none posted)