The current development kernel is 2.5.41
, which was released
by Linus on October 7.
"Mucho merges with the 'A-Team' (Alan, Al, Alexey, Andrew, Anton,
Arjan, Arnaldo and Art), but the 'M-Team' (Maksim, Marcel, Martin's and
Mike) is a close runner up.
" There's a bunch of patches from Alan
Cox, more disk management reworking, more memory management work, some SCSI
work, a big ALSA update, an ISDN update, some kbuild work, a big S390
update, and numerous other fixes. The long-format changelog
has all the details.
Linus's BitKeeper repository, which is destined to become 2.5.42, currently
contains some driver model work (with an emphasis on IDE devices), another
s390 update, the large block device patch (see below), the beginning of the
"asynchronous I/O for networking" merge, the return of IDE tagged command
queueing support, indexed directories for the ext3 filesystem, a number of
NUMA and discontiguous memory enhancements, long lists of small patches via
Dave Jones and Alan Cox, and quite a few other fixes and updates.
The current development prepatch from Alan Cox is 2.5.41-ac2. Since 2.5.41 came out, the -ac
patches have been mostly concerned with compilation fixes and other small
The latest 2.5 status summary from Guillaume
Boissiere is dated October 9.
The current stable kernel is 2.4.19. Marcelo released 2.4.20-pre10 on October 8. The lists of
patches applied are getting smaller, suggesting that there just might be a
release candidate before too long.
Comments (none posted)
Kernel development news
The lengthy BitKeeper flame war was not entirely without useful results.
Some developers expressed a wish to have a better view into what patches
were being applied without having to run BitKeeper to extract them; the
response was the creation of a couple of "bk commits" mailing lists on
vger.kernel.org. Every time Linus merges a patch, the "bk-commits-head"
list gets a message containing that patch. A similar list (bk-commits-24)
exists for those who want to track what's up with the 2.4 kernel instead.
Now there's no excuse for not knowing what got merged into 2.5 ten minutes
See the vger majordomo
page for information on how to subscribe to these lists.
Comments (none posted)
A linux-kernel reader recently complained
that Red Hat had applied a patch to the kernel in its 8.0 distribution
which made the sys_call_table
data structure unavailable to
modules. He will not have been pleased with the 2.5.41 kernel release,
which did the same thing.
sys_call_table is a special table used to dispatch system calls
within the kernel. It is a simple array, indexed by the system call number
passed in from user space. The reason for wanting this array to be
exported, of course, is to allow modules to add or modify system calls. A
classic example is a module implementing the "streams" interface, which is
unlikely to ever be part of the mainline kernel. Some users need streams,
though; an exported system call table allows them to load a module and have
the streams call work as expected.
So why would this capability be taken away? The stated reason is that
tweaking the system call table is nonportable and unsafe. Each
architecture has a different system call table format, so code which wants
to be portable has to understand how each architecture does things. There
is also no locking mechanism for the system call table, so run-time changes
are subject to race conditions. And finally, there are even errata
problems on some processors; changing a table used the way
sys_call_table is used can have unfortunate and unexpected
Many of these problems could be worked around with a bit of coding. But
the simple fact is that many kernel developers do not want loadable modules
to be able to add or change system calls. Binary modules are tolerated as
long as they stick to the "published" interfaces and implement
straightforward features (such as device drivers and filesystems). A
module which can add or change system calls can go well beyond that
interface. Removing access to the system call table keeps modules in their
Working around this problem not all that difficult for modules which need
to do so. A patch was quickly posted which
made streams work again, for example. The solution is to have a set of
stub system calls wired into the kernel; when the associated module is
loaded, the stubs can make the appropriate calls with the necessary locks.
Otherwise they return an ENOSYS error.
Comments (none posted)
One would think that, after Eric Raymond's experience with trying to
overhaul the kernel configuration scheme, nobody else would want to venture
into that area for a long time. One would be wrong, however; Roman Zippel
has been working on his "LinuxKernelConf" package for some time, and has
recently posted version 0.8
, with a
statement that it is ready for inclusion.
LinuxKernelConf, like the ill-fated CML2 effort, defines a new
configuration language (specification) and
creates a single parser that can be used by all
configuration interfaces. The new language is purely declarative, unlike
the old one, which was really an imperative programming language. A
configuration file (there are now many, spread throughout the source tree)
contains declarations for the various configuration options, including all
the relevant information in one place. A typical entry looks something
bool "Network packet filtering debugging"
You can say Y here if you want to get additional
messages useful in debugging the netfilter code.
Note that, among other things, this scheme includes the help information
with the rest of the configuration details.
Unlike CML2, Mr. Zippel's scheme avoids fancier scripting languages and
works with basic tools. That will help to avoid one set of flame wars.
LinuxKernelConf may well stumble over a different obstacle, however: the
(quite nice) graphical configuration tool is built on Qt. That is, in
fact, the source
of Linus's biggest concern about this patch:
But the fact that xconfig depends on QT is going to make some
people hate it.... In other words, I really think this needs to
pass the linux-kernel stink test. Will Al Viro rip your throat out?
Will it generate more positive feedback than death threats?
In fact, there have been very few death threats so far, perhaps because not
too many people have looked at the code. Regardless of the level of
promised violence, however, it looks like LinuxKernelConf may be merged
with some evasive action: the graphical interface will simply be omitted.
The kernel will thus ship with the basic configuration language; anybody
who wants to use a graphical tool will need to obtain and install it
separately. One a few other, smaller issues are resolved, it looks like
Linus may go ahead and merge this patch.
Comments (4 posted)
One set of patches which Linus has merged into his pre-2.5.42 BitKeeper
tree is the "large block device" patch by Peter Chubb. Current Linux
systems are limited to a mere 2TB in any one block device; this limitation
is beginning to hurt users of very large RAID arrays. With the LBD patch,
that limitation goes away.
The solution, of course, is to simply redefine the sector_t type
as a 64-bit quantity. Mr. Chubb's patches (which can be found in the
"patches" section below) do exactly that. Generally, the
transition is not that hard; the bulk of the changes, seemingly, are to
format strings in printk calls. Much of the rest is changing
variables which were defined as int or long over to the
For the most part, it is said to work. Note, however, that software RAID
volumes are still limited to 2TB.
Comments (none posted)
Patches and updates
Core kernel code
Filesystems and block I/O
Benchmarks and bugs
- Ulrich Drepper: nptl 0.2.
(October 4, 2002)
- Brian F. G. Bidulock: export of sys_call_table . Makes the Linux streams module work without an exported <tt>sys_call_table</tt>.
(October 9, 2002)
Page editor: Jonathan Corbet
Next page: Distributions>>