Kernel development

Kernel release status

The current development kernel is 2.6.0-test11, otherwise known as "Beaver in Detox," which was released by Linus on November 26. This release contains a very small number of important fixes; the long-format changelog has the details.

The -test11 announcements says "And after that it will be up to Andrew to say how to go on from here." Even so, Linus's BitKeeper tree contains a handful of other patches which, presumably, will find their way into a release at some point.

The current stable kernel is 2.4.23, which was released by Marcelo on November 28. No changes were made between -rc5 and the final release.

Comments (none posted)

RTAI 3.0-test1 released

The first test release for RTAI 3.0 is now available. RTAI is an extensive set of real-time extensions for the Linux kernel; this release includes a great many improvements, which are described in the announcement.

Full Story (comments: none)

The first ALSA 1.0 release candidate

The Advanced Linux Sound Architecture (ALSA) project has been working at the creation of a new audio subsystem for the Linux kernel (along with user-space support) since early 1998. Now, almost six years later, the project has announced its first 1.0 release candidate. This release is not that far removed from what is in the 2.6.0-test11 kernel; still, it might be a good time for audio enthusiasts to test things out one last time.

Comments (1 posted)

What future for 2.4?

After the 2.4.23 release, maintainer Marcelo Tosatti let it be known that the development period for the 2.4 series is coming to an end. His plans are to accept relatively intrusive patches for 2.4.24 - especially driver patches. But, starting with 2.4.25, only serious bug fixes will be accepted. People will be running 2.4 kernels for some time yet, but the 2.4 series will not be acquiring new features.

The result of this sort of announcement is always predictable: people start coming forward with the the patches that they feel, for whatever reason, absolutely have to be merged before the gate closes. One of those is Jeff Garzik's "libata" driver, which provides much improved serial ATA support. Marcelo initially said that he would incorporate libata, but has since changed his mind, saying that people who want libata should use 2.6.

The big discussion, however, concerned the inclusion of the XFS filesystem. XFS is relatively controversial because it requires some significant core VFS changes, and not everybody is happy with the quality of the code. There was enough clamor, however, that Marcelo has relented to the extent that, if some of the core filesystem maintainers can be made to agree, he will let XFS in.

The reasoning behind the policy change for 2.4 is that the 2.6 kernel is on the horizon. 2.6.0 may well be released before a 2.4.24 kernel could be prepared. At that point, attention is expected to shift to 2.6, and there won't be much interest in 2.4 anymore. This approach does worry some people who remember that the 2.4 kernel took almost a year to truly stabilize after 2.4.0 came out. If 2.6 follows the same path, Linux users could be left for several months with no kernel which is being updated with new drivers, bug fixes, etc.

The general expectation, however, is that the early part of the 2.6.x series will be rather more successful than 2.4 was. The 2.6.0-test kernels seem to be far more stable than 2.4 was at this stage, and there is a high level of confidence in Andrew Morton's willingness and ability to stabilize things further. Not everybody realizes how differently the development process is working this time around. The year-old feature freeze has (mostly) held, which is a nice difference. But the big change is that Linus will be handing 2.6.0 to Andrew Morton from the beginning. In the past, Linus has always continued to manage the stable kernel releases until he felt confident in moving on to the next development series. Linus, by his own admission, is not the best release manager for a stable kernel; he would much rather be breaking things. So his early handoff of 2.6 could make a big difference in how quickly that kernel becomes truly usable.

That said, 2.6.0 is still not going to be the best kernel to use to run your nuclear power plant. A small set of fixup releases will certainly be required first. But the confidence in 2.6 is high enough that the distributors are looking in that direction for their future releases. There is little interest in building a new distribution release on 2.4; that, more than anything else, is the reason for putting 2.4 into a "critical fixes only" mode in the near future.

Comments (4 posted)

No fear of the fire engine

The Linux developers have long, and with reason, been pleased with the performance of the kernel's networking subsystem. For various reasons, there is also a longstanding rivalry between the Linux networking hackers and their Sun counterparts. So when The Register posted an article about the "Fire Engine" networking stack which will be part of future Solaris releases, it drew some attention. This quote from John Fowler, Sun's software CTO:

also didn't help.

The dissection of Sun's claim was quick to begin. It was pointed out that we don't know which version of Linux is being referred to in the quote. There's a lot of differences between the 2.4 and 2.6 kernels, and it would not be quite sporting for Sun to be comparing its upcoming, unreleased technology with an old version of Linux.

Sun's performance improvements appear to be based on the use of "TCP Offload Engine" (TOE) technology. The idea of a network adaptor which can take on the network protocol overhead is not particularly new; such hardware has been available for many years. The Linux networking hackers have always had a low opinion of the TOE approach, however. TOE hardware may offload a bit of work from the processor, but it suffers from a number of disadvantages:

• When you use TOE hardware, you have just moved your networking stack into a firmware-based, close-source module. This code can not be inspected, fixed, or improved.

• TOE-based networking suffers from latency problems. The setup and teardown of network connections still requires the processor's intervention, and that means several round trips over the bus for each connection.

• As Larry McVoy heard from "Sun employee #1," processors are getting faster much more quickly than TOE hardware is. Even if a TOE adaptor performs reasonably when it is released, it will be quickly outstripped by processor-based TCP implementations.

The 2.6 networking stack is happy to offload some functions to smart interfaces; examples include packet checksumming and TCP segmentation. But the full TCP offload approach is likely to remain unpopular into the future.

In general, the networking hackers do not feel threatened by "Fire Engine." That didn't stop them from having a discussion of how Linux networking could be made faster, however. The conversation was based around a shopping list of possible improvements posted by Andi Kleen. This list includes a number of good ideas, but the bulk of the debate concerned a relatively obscure topic: timestamp generation.

Certain applications want to get each packet packaged with a timestamp saying exactly when that packet was received. Tools like tcpdump, for example, make use of this capability. The socket interfaces were designed in such a way that the networking subsystem cannot know if any particular packet needs to be timestamped or not; as a result, it generates timestamps for all incoming packets, even though they are rarely used.

The problem is that this timestamp generation gets to be expensive when you have thousands of packets flowing through the system every second. Depending on the architecture Linux is running on, generating the timestamp can involve talking to a (slow) off-CPU timer or moving cache lines frequently between processors. Improving the timestamp generation might be the most straightforward way of speeding up Linux networking, at least at the high end.

That fix is not entirely easy, however. Networking maintainer David Miller is unwilling to make any changes that would reduce the accuracy of the timestamps returned to user space. Any such changes would be seen as an API change; somebody, somewhere, would be badly affected by it. The proper solution, as proposed by David, is the creation of a new fast_timestamp_t type which is quicker to generate, but which can be converted to a real time when the need arises. The optimal implementation of this type would be highly dependent on the underlying architecture; on many systems the CPU cycle timer could be used, but that approach would not work universally. A default, architecture-independent "fast timestamp" implementation is easy to add, however. Creating that sort of structure for the architecture maintainers to play with may be one of the first things to happen when the 2.7 series opens up.

Comments (4 posted)