Kernel development [LWN.net]

Release status

Kernel release status

The current development kernel is 2.5.47, which was released by Linus on November 10. Changes this time around include more IPSec work (to the point that it works now), a big kernel timer cleanup, continuing work on the large page mechanism, a PowerPC64 update, some XFS updates, improvements to the new crypto API, an ALSA update, a zero-copy NFS server patch, and lots of other fixes and tweaks. The long-format changelog has the details.

Linus's (pre-2.5.48) BitKeeper tree contains more timer cleanups, a rewrite of the software suspend code, Rusty Russell's in-kernel module loader, continuing IPSec work, and various other fixes.

The current development kernel prepatch from Alan Cox is 2.5.47-ac2. It includes the latest ACPI code, some device mapper fixes, some new IDE work, and a number of fixes.

The latest 2.5 status summary from Guillaume Boissiere is dated November 13.

The current stable kernel is 2.4.19. Marcelo has released no prepatches since the first 2.4.20 release candidate came out on October 29.

Comments (none posted)

Kernel development news

2.5 kernel progress charts

Guillaume Boissiere, keeper of the 2.5 Kernel Status Summary, has put together a couple of images showing how features were merged into the 2.5 kernel over time up to the feature freeze. Have a look at the simple progress chart and the compounded chart (also shown at right).

Comments (none posted)

The new module loader

Linus has stated that the October 31 feature freeze date was a deadline for submissions to him, not for actual merging. He has been restrained in what he has merged since then, but one significant change that will show up in 2.5.48 is the new module loader by Rusty Russell. This patch was covered briefly here back in September. As of this writing, the code that has been merged is missing a few little features, like modversions, module parameters, module license checking, and device table support (which is needed to make hotplugging work). Fixes for these omissions are promised for the near future.

Meanwhile, the new code is simpler for both the kernel and user space; it is also safer in a number of ways. It does, however, require a new set of module utilities to work; these can be obtained as a source tarball from Rusty's site.

Comments (none posted)

Some documentation for 2.5 IPSec

As of the 2.5.47 kernel, the new, native Linux IPSec implementation actually (sort of) works. Bert Hubert has been playing with this code, and has put together a quick HOWTO on how to make it go. Anybody who is interested in a solid, stable IPSec implementation in 2.6 (and almost all of us are, whether we realize it or not) should consider having a look and testing it out.

Comments (none posted)

What's to become of devfs?

From a recent posting by Alexander Viro:

During the last couple of weeks I'd done a lot of digging in devfs-related code. Results are interesting, and not in a good sense

He continues with a long list of changes he would like to make to the devfs code; it's a massive set of cleanups which would, it is claimed, shrink the devfs code base considerably and make things work better. Comments were requested on the proposal; the few that came in were favorable.

The posting led to an entirely different sort of discussion, however. As Ted Ts'o asked, how many people are actually using devfs?

In any case, if there aren't all that many people using devfs, I can think of a really easy way in which we could simplify and clean up its API by slimming it down by 100%......

The question is worth asking. Despite the fact that devfs has been in the 2.4 kernel since it first shipped, very few distributions are turning it on for their customers. The devfs way of doing things has failed to take over the world.

And, perhaps more to the point, there is a new approach to dynamic device management that, while not yet actually implemented, is attracting interest. The combination of the /sbin/hotplug mechanism and the device model provides (or can provide) everything that is needed to create devfs-like filesystems in user space. The device model, via the sysfs (formerly driverfs) filesystem, provides a complete view of the state of the system, including all attached hardware. /sbin/hotplug gives user space the ability to know about (and react to) changes in the system state. Using that information, user-space code can populate a device directory hierarchy that implements just about any kind of policy that one could imagine.

All it takes is somebody to hack up the remaining pieces; a user-space devfs could easily be a reality in the 2.5 development series. And, since it lives in user space, there are no real issues with the feature freeze.

Of course, none of this points to a removal of devfs in this development series. Removal of features violates the feature freeze as surely as additions do. It is also standard practice to leave such features in place (though "deprecated") for one stable series to give users time to make the transition. So, even if the decision to remove devfs is made (and that certainly has not happened at this point), it will be around for a while.

Comments (17 posted)

Kexec

One of the remaining features that may yet get merged is the "Kexec" patch by Eric Biederman. This patch performs what may seem to be a straightforward task - it reboots the system directly into a new kernel. Things are not always as simple as they seem, however, and this patch has been through an extended period of reworking on its way toward (probable) inclusion.

One might wonder what the use of Kexec is, given that people have somehow managed to reboot their systems for years now. Kexec differs from a normal reboot in that the old kernel loads the new one, and jumps to it, directly. There is no need to reset the hardware and go through the whole BIOS startup routine. So, reboots are faster and, perhaps, more reliable. There is also an obvious advantage for kernel developers, who can simply say "boot that image" without having to tell a boot loader (such as LILO) about it first.

Rebooting on the fly in this manner is not an entirely easy thing to do. The new kernel, after all, probably wants to sit in the same part of memory as the current one. So the new kernel can not be put into its real place until the old kernel has finished shutting down gracefully. But, by that point, the old kernel is no longer in a position to load the new one from user space, or from anywhere else.

So the Kexec code has to start by buffering a copy of the new kernel somewhere else in memory. When user space indicates that it has a new kernel to boot, the Kexec code allocates a big pile of memory pages to hold the kernel code. This code is spread out through (non-high) memory, and is not contiguous or otherwise ready to execute. Also allocated along with the memory for the kernel code is the "reboot code buffer." This buffer is typically just a single page.

When the time comes to boot into the new kernel, the Kexec code does the following:

Shuts down the kernel, and tries to reset devices to a known state. The code does not unmount filesystems, kill processes, etc.; that work is expected to have been done by user space prior to the reboot call.
Copies a small bit of assembly code into the reboot code buffer. This code's job is to take the set of pages holding the new kernel and copy them into their real destination - typically overwriting the old kernel.
Jumps (via a return, actually) into the new kernel.

The original Kexec patch created a kexec() system call which would load the new kernel image as described above, and immediately reboot into that image. That approach, however, wasn't quite what Linus had in mind, even though Linus likes the Kexec idea in general. Why not, asked Linus, split up the operations of loading the new kernel and rebooting into it?

The reasoning for splitting these operations has mostly to do with other possible uses for Kexec. For example, one can imagine all kinds of things that could be done when the kernel panics: boot into a debugger or crash dump generator, or just bring up that old 2.2 kernel that always worked. The problem is that, when the system has gone into a panic, you really do not want it digging around in the filesystem looking for an image to boot; that needs to have been set up ahead of time. And the only way to do that is to split the load and reboot steps.

So the current patch has a kexec_load() system call which loads a kernel image into memory. Then, a new LINUX_REBOOT_CMD_KEXEC command for the existing reboot() call finishes the task. This version of Kexec still does not handle the panic case, but it has most of the infrastructure needed to do that.

Comments (3 posted)

Patches and updates

Kernel trees