See also: last week's Kernel page.

Kernel development

Ted Ts'o posted a (lengthy) new 2.4 status liston September 13.

The current stable kernel release is 2.2.17. The stable kernel prepatch is up to 2.2.18pre6.

There is a constant call for the inclusion of the NFS patches in 2.2.18. Protesters have begun blocking streets in Swansea. The basic problem is the same as it has been for a while: the standard Linux NFS implementation works poorly, especially if you are trying to set up a big server. The available fixes make things a lot better - to the point that many distributions include them with their kernels.

Alan seems to be softening his position on this one; some recent postings from him have suggested that NFS will go into a stable kernel soon, perhaps even into 2.2.18. It now seems to be a matter of stabilizing some of the other changes and waiting for the time to be right.

A new 2.0.39 prepatch is out; this one is 2.0.39pre8. The pre7 patch was supposed to be the last, but evidently a problem of the "brown paper bag" variety turned up...

The kernel debugger discussion continues, without a whole lot in the way of new and interesting contributions. There are two well entrenched positions, and the debate does not seem to be convincing many people to change their minds.

The pro-debugger debugger case was well stated by Keith Owens, modutils and kdb maintainer, in The case for a standard kernel debugger:

Seven of the twelve architectures in the standard kernel already have built in debuggers. Where is the evidence that these architectures have more bad patches because of the presence of the debuggers?

For those who can't fathom why Linus would be opposed to the inclusion of a kernel debugger, a reading of his explanationmight help to clear things up.

I don't think kernel development should be "easy". I do not condone single-stepping through code to find the bug. I do not think that extra visibility into the system is necessarily a good thing....

I'm a bastard. I have absolutely no clue why people can ever think otherwise. Yet they do. People think I'm a nice guy, and the fact is that I'm a scheming, conniving bastard who doesn't care for any hurt feelings or lost hours of work if it just results in what I consider to be a better system.

One nice thing about Linus, one does not usually have to wonder about just where he stands...

Andrea Arcangeli, meanwhile, has made available the slides from a recent talk he gave on the available kernel debugging tools.

MontaVista's preemptable kernel got some attention this week following the company's press release announcing its availability. It's time for a quick look at what MontaVista has done.

In most Unix systems since the very beginning, kernel code has had a hold on the processor for as long as it wanted. While user code can be preempted at any time, kernel code keeps on running until it explicitly yields control. Kernel developers used to take great advantage of that fact, since they didn't have to worry about surprises from shared access to resources.

Life has gotten harder with the arrival of SMP systems; kernel code must now be prepared to cooperate with more kernel code running on other processors. It is still true, however, that Linux kernel code is not kicked off a processor involuntarily. (OK, there are a few small exceptions, such as interrupt handling).

The non-preemptable kernel brings about problems, however. Sometimes the system must be able to respond very quickly to an event. Many real-time tasks require very quick response, but even dealing with everyday audio and video streams can be a problem if the system reacts too slowly. An operating system which cannot preempt its own kernel code is going to be susceptible to this sort of long latency; if some kernel function gets going on a long task, it may not give up the processor for way too long a time.

What MontaVista has done is to make the kernel code preemptable. The idea is not new; Linus mentioned the possibility back in July. MontaVista just jumped out ahead of the pack by offering an implementation well ahead of the beginning of the 2.5 development series.

MontaVista's kernel is not completely preemptable. Whenever code is handling interrupts, doing bottom half processing (essentially an extension of interrupt processing), or running the scheduler it can not be preempted. More significantly, any code which is holding a spinlock will not be pushed out of the CPU. This restriction makes sense for performance and deadlock reasons, but also greatly limits the preemptability of the kernel. Much of what is done in the kernel happens under the protection of one or more spinlocks.

And, in fact, a set of latency benchmarksperformed on the MontaVista kernel by Benno Senoner show that, while the kernel performs better, it still has significant latencies. In particular, the system can be quite slow to respond when it is performing significant disk activity. Mr. Senoner also tested Ingo Molnar's latest low-latency patch with significantly better results.

So MontaVista's kernel is perhaps not the ultimate hard real-time solution that the company would like. It is a significant bit of work, though, that may well find its way into the 2.5 development series, whenever that may begin. More information on MontaVista's work can be found in this white paper published on LinuxDevices.com.

A proposal for a Linux kernel patch management system was posted this week. The proposal is the work of Linus Torvalds, Ted Ts'o, Daniel Quinlan, and Sebastian Kuzminsky, who is writing the code to implement it. The current system, which can be described as "send patches repeatedly to Linus and/or the subsystem maintainer, then watch new releases to see if it appears" tends not to work very well for a lot of people, so something more organized is called for.

The proposed system is relatively straightforward. A mailing address would be set up to accept patches; a program sitting behind the address will store and log them. Mechanisms can be put into place to track the outstanding patches, perform certain types of automated testing, and more. With luck, the new system will make life easier for both Linus (who is buried in patches) and the kernel developers (who never know what the status of their patches is).

No more IDE backport for 2.2. Andre Hedrick, maintainer of the Linux IDE subsystem, has announced that he will no longer be able to support the 2.2 backport of his IDE work. This port has seen heavy use, and is included by a number of vendors in their standard kernels. It's valuable work, but getting the 2.4 kernel stabilized is more important, for now. The backport will, hopefully, remain available, as Bartlomiej Zolnierki has indicated his willingness to maintain it in the future.

Watch out for ECN. Support for IP Explicit Congestion Notification (ECN) started finding its way into the kernel with 2.4.0-test3, with -test7 providing a full implementation. ECN, as described by RFC2481, allows routers to set a bit inside an IP packet to indicate that the route taken by the packet is experiencing congestion. A compliant implementation should then throttle back its transmission rate in much the same way as it would when packets start getting dropped. The advantage with ECN is that congestion can be indicated without actually dropping packets, leading to fewer retransmissions.

It turns out, however, that some firewalls from a very large network equipment manufacturer do not deal with ECN correctly; in fact, they simply drop packets that attempt to use the ECN feature. The result is that, if you are using ECN, a substantial portion of the Internet (a figure of 8% has been posted) is unreachable. This was not the desired result.

For now, people running development kernels will almost certainly want to turn off CONFIG_INET_ECN to avoid this problem. The longer term solution will probably involve pressure to get the non-compliant systems upgraded, and, perhaps, some mechanism to detect connections that are broken by ECN and automatically turn it off.

Other patches and updates released this week include:

• David Howells posted a patch which moves a number of the WINE "system calls" into the kernel, with a significant improvement in performance. He is looking for comments on the idea; Linus is not opposed to it.

• Jens Axboe has released version 0.0.2c of his CD-RW packet writing module.

• User beancounter patch IV-0010, a process resource accounting mechanism, was posted by Andrey Savochkin.

• Aki Laukkanen posted an announcement of his "streamfs" filesystem, which is oriented toward audio and video streaming applications.

• Modutils 2.3.16 has been released by Keith Owens. Given that questions about the new module locations still turn up on linux-kernel, a number of people should probably get this new version.

• Jeroen Vreeken has posted version 0.7 of his video loopback driver.

• Juan Quintela has released version 0.0.4 of the "memtest" suite - a set of tools for testing the memory management system.

• Rik van Riel has announced the latest version of his virtual memory patch; there is also a scheduler patch available.

• acl-0.6.5, the latest stable release of the access control list patch, is available.

• usbview 0.9.0, a tool for displaying the topology of a USB bus, is available.

Section Editor: Jonathan Corbet

For other kernel news, see: Kernel traffic Kernel Newsflash Kernel Trap 2.5 Status

Other resources: L-K mailing list FAQ Linux-MM Linux Scalability Effort Kernel Newbies Linux Device Drivers

Next: Distributions