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
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
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
and the compounded
(also shown at right).
Comments (none posted)
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)
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
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)
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
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
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
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
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)
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)
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
- 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
Core kernel code
Filesystems and block I/O
Benchmarks and bugs
Page editor: Jonathan Corbet
Next page: Distributions>>