[LWN Logo]
[LWN.net]

Sections:
 Main page
 Security
 Kernel
 Distributions
 Development
 Commerce
 Linux in the news
 Announcements
 Letters
All in one big page

See also: last week's Kernel page.

Kernel development


The current development kernel is 2.5.8, which was released on April 14. It contains a number of low-level memory and buffer management improvements by Andrew Morton, another set of IDE patches from Martin Dalecki (see below), Jens Axboe's IDE tagged command queueing code (discussed here last week), a large set of ReiserFS fixes, a large PowerPC64 update, lots of USB updates, quite a few networking fixes, the usual set of VFS changes from Alexander Viro, and many other fixes and updates.

Note that Linus warns: "The TCQ stuff is definitely experimental, you should probably configure it out for now."

No 2.5.9 prepatches have been issued as of this writing.

The latest patch from Dave Jones is 2.5.8-dj1; it fixes a number of problems but Dave has not dug too deeply into the patch queue yet.

Guillaume Boissiere's latest 2.5 status summary was released on April 17.

The current stable kernel release is 2.4.18. The latest 2.4.19 prepatch from Marcelo (produced when he wasn't busy getting thrown out of the U.S.) is 2.4.19-pre7; it adds a very long list of new fixes and upgrades, but no major changes.

There were no 2.4 prepatches from Alan Cox this week.

The right way to clean up the IDE code. Working on the IDE subsystem seems to be a difficult and thankless task - especially if you are not always concerned about the troubles you create for some users. Martin Dalecki found himself on the firing line again after releasing his IDE 36 patch, which included the following:

Remove sector data byteswapping support. Byte-swapping the data is supported on the file-system level where applicable. Byte-swapped interfaces are supported on a lower level anyway. And finally it was used inconsistently

There was only one problem: some people use and rely on that byte swapping feature. Filesystems can handle byte swapping in some situations - especially with their own metadata - but sometimes it is necessary to deal with a disk where everything is swapped. In particular, it seems that disks from TiVo systems require swapping to be readable on a Linux box.

It can be dangerous to interfere with hackers trying to play with their TiVo systems.

Despite the complaining, nobody is standing up for the old byte swapping implementation. It only worked in the (slow) programmed I/O mode, and could, in especially unlucky situations, lead to disk corruption. This feature clearly needed to be fixed in some way. But a number of people would have rather seen a replacement be provided before the old implementation was yanked.

Linus, however, does not agree:

The fact is, many things are easier to fix afterwards. Particularly because that's the only time you'll find people motivated enough to bother about it. If you were to need to fix everything before-the-fact, nothing fundamental would ever get fixed, simply because the people who can fix one thing are not usually the same people who can fix another.

In other words, a better byte swapping implementation simply is not going to happen until somebody really has to do it.

This better implementation, in fact, will probably not live in the IDE subsystem, and, thus, will probably not be done by Martin. The consensus seems to be that full byte swapping belongs in the loopback driver, where it can be slotted in when needed. No implementations have been posted, but it should not be that difficult for somebody to do.

Where are the VM updates for 2.5?. Mike Fedyk asked:

Why haven't any of the -aa VM updates gone into 2.5? Especially after Andrew Morton has split it up this is surprising...

Given the amount of VM work that happened just before the 2.5 fork, and given that Andrea's changes are said to improve performance and stability in a number of ways, it is interesting that VM development seems to have stopped in 2.5. Appearances can be deceiving, though: Andrew Morton's buffer management and I/O work certainly affects memory management. Rik van Riel, William Lee Irwin, and others have gotten VM-related patches into 2.5. Nonetheless, not much VM work is happening in 2.5. Andrew Morton posted a few reasons why that might be, including:

  • Not much work is happening with 2.5 VM. The VM hackers are mostly still working with 2.4; the job there is incomplete, and it provides a more stable platform for VM developments (such as Rik van Riel's reverse mapping (rmap) code).

  • Other work, such as the buffer management changes, tends to conflict with extensive VM changes.

  • The general direction of VM development in 2.5 is still unknown. For example, no decision has been made on the inclusion of rmap in 2.5. There isn't even a 2.5 rmap patch yet.

Andrea Arcangeli, meanwhile, would like to see his changes in 2.5:

The fact is that in all the feedback I got so far I didn't seen anything that surpasses my vm-33 updates, certainly not mainline without them, certainly not the rmap patch either, and this is why I'm assuming vm-33 is the right thing to merge at this point in time into both 2.4 and 2.5.

Andrea also states that he is done with 2.4 work unless a problem comes up.

Linus has not chimed in with his view of where the VM work should go, so there is really no way of knowing what might get merged when. This could be cause for a bit of concern. The 2.3/2.4 experience demonstrated, clearly, that VM changes should not be left to the end of a development cycle. VM work can take a very long time to stabilize, so any big changes should be in place well before one even begins to think about stable releases.

The Linux Trace Toolkit is now available for the 2.5 kernel. LTT allows for detailed, dynamic tracing of the kernel; it can be invaluable for tracking down obscure, timing-related problems. LTT is shipped by some vendors (especially embedded Linux companies), but is not part of the standard kernel. Karim Yaghmour, author of LTT, would like to change that:

In the past, many have shown interest and support for LTT's inclusion in the standard kernel tree. I won't fill this mail with names, but Alan Cox, for instance, is one of them

LTT is a useful tool for looking inside the operation of the kernel. There is no word, of course, on whether it will eventually be merged into the mainline kernel; it remains, however, just one patch away.

Other patches and updates released this week include:

Kernel trees:

Core kernel code:

Development tools:

Device drivers

Kernel building:

Miscellaneous:

Networking:

Ports:

Section Editor: Jonathan Corbet


April 18, 2002

For other kernel news, see:

Other resources:

 

Next: Distributions

 
Eklektix, Inc. Linux powered! Copyright © 2002 Eklektix, Inc., all rights reserved
Linux ® is a registered trademark of Linus Torvalds