See also: last week's Kernel page.

Kernel development

The latest 2.4 status page was posted by Ted Ts'o on August 9.

The current stable kernel release is 2.2.16. The latest prepatch is 2.2.17pre16, which was released on August 9. There is no word on when the official stable kernel release might happen.

Crypto in the kernel? Inspired, perhaps, by the twin blessings of the liberalization in U.S. crypto export laws and the expiration of the RSA patent (September 20 or 21, depending on who you ask), more people are wondering about when cryptographic code will make it into the Linux kernel. The answer is, seemingly, that it's getting closer. But a kernel with full cryptographic support is still going to be a little while in coming.

As an initial step, the International Kernel Patch has been available from kernel.org (in the pub/linux/kernel/crypto directory) since mid-July. This patch provides a basic cryptographic infrastructure, which is used mainly to implement encrypted filesystem support. The patch does not look like it will be part of the 2.4.0 release, though it looks like work to start integrating it could happen for later 2.4 versions.

So encryption of local data will be covered, eventually. What about network communications? The obvious code to merge would seem to be FreeS/WAN, an implementation of the IPSec protocols. When one investigates that idea, however, one discovers that the crypto cold war is not quite over yet.

The FreeS/WAN project is located in Canada as a way of avoiding the obnoxious U.S. laws that were in effect when the project was founded. An interesting interaction between U.S. and Canadian law required that any cryptographic code of U.S. origin not be exported from Canada. As a way of insuring that the FreeS/WAN code remained legitimately exportable and usable, the project adopted a rule that no code could be accepted from the U.S. Everything that was to be part of FreeS/WAN had to be developed elsewhere. That rule remains in effect, seemingly, because the FreeS/WAN people are afraid that the U.S. could change its mind and restrict cryptographic code anew.

There is nothing preventing FreeS/WAN from going into the Linux kernel. But Linux kernel code is far from static; as soon as FreeS/WAN is part of it people will start changing it. Patches will surely flow in to fix bugs, improve performance, add features, and so on. But the FreeS/WAN project will not accept those patches - at least, not those which come from (or through) the U.S.

So, if FreeS/WAN is to go into the kernel, the code will essentially be forked. Since changes from the Linux side will not go back to the main code base, the kernel developers will be faced with the choice of either maintaining a separate patch to apply to each FreeS/WAN release, or simply forking off a separate version of FreeS/WAN altogether. This is a situation that does not benefit anybody; it may be time for FreeS/WAN to reconsider its position.

How did JFFS get into the kernel? The 2.4.0-test3 release included one interesting surprise: the Journaling Flash Filesystem (JFFS). JFFS was originally developed by Axis Communications, and is intended to provide a stable filesystem on flash memory in embedded systems. It's a nice bit of code, but some were surprised to see it show up in the mainstream kernel at such a late date.

It turns out it slipped in by mistake. It was included as part of the "memory technology devices" patch, which had been planned to go in for some time. Once it was there and didn't cause any troubles, there didn't seem to be any real point in taking it out again. So JFFS remains.

One linux-kernel poster, however, saw something more sinister here. He posted a long and somewhat offensively-worded message accusing Linus of having integrated JFFS to meet Transmeta's needs for "web pad" devices and such. The accusation is clearly without basis - as others have pointed out, Linus is probably capable of maintaining a separate kernel branch for Transmeta if need be. But accusations of vendor bias seem to be on the increase, unfortunately. It will not be a good thing if the kernel developers increasingly have to defend themselves against such attacks.

The Linux Test Project was announced this week by Nathan Straz of SGI. The project has set out to provide a comprehensive regression test system for the Linux kernel - something that has been missing for a long time. They have 96 tests available now, and are looking to add many more. They are looking for input on what a full test suite should look like; there will also, hopefully, be a BOF on the subject at LinuxWorld.

Other patches and updates released this week include:

• Rik van Riel has posted a virtual memory patch which implements many of the changes described in his new VM subsystem design discussed in last week's LWN. The design itself, after some discussion, has essentially received Linus's blessing, and may yet find its way into a 2.4.x kernel.

• Michael Elizabeth Chastain has released the sixth and (probably) final draft of his documentation of the kernel build system.

• Modutils-2.3.14 was released by Keith Owens.

• For those who want another new kbuild system, Paul Vojta has released one called "qconfig".

• Andreas Gruenbacher has announced the release of version 0.6.0-pre38 of the Linux access control list (ACL) patch.

• Gregory Leblanc has started work on a Linux RAID FAQ.

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