The current development kernel is 2.6.0-test10
, finally released
by Linus on November 23. This
patch contains a month's worth of accumulated fixes for serious bugs, and
not a whole lot else. Linus notes that there is still a problem associated
with preemption out there; the kernel preemption code itself is likely not
at fault, but some subsystem or driver out there somewhere is not being
entirely preempt-safe. That problem had not been tracked down as of this
The long-format changelog contains the
details for the patches incorporated in this release.
Incidentally, -test10 has been dubbed the "stoned beaver" release.
Linus also laid out his thinking for the future:
I'm planning/hoping on basically turning this over to Andrew, and
let him decide to make the final 2.6.0 or not. Timing-wise Andrew
is apparently going to be off for a few weeks, so regardless of
whether this turns out to be rock solid or not, we'll have a few
weeks of final testing before that were to happen. Which means that
I might still end up making a test11 if Andrew hasn't come back and
we find something that warrants it.
Linus's BitKeeper tree holds a small number of additional fixes.
The current stable kernel is 2.4.22, but its time is coming to an
end. Marcelo released 2.4.23-rc3 on
November 21, with the idea that it would become the final release.
Reality dictated otherwise, with the result that 2.4.23-rc4 came out on the 24th, and 2.4.23-rc5 on the 25th. The idea, of course,
is that this one will become the final release; stay tuned.
Comments (none posted)
Kernel development news
The Linux Security Module (LSM) patch was intended to enable the creation
of a wide variety of security regimes for Linux systems. So far, the main
user of the LSM functionality has been the NSA SELinux module. But there
are signs that other security-oriented developers are beginning to make use
of LSM to implement different approaches.
The latest such is the BSD Secure Levels
patch posted by Michael Halcrow. This patch is intended to create
something resembling BSD's secure level capability for Linux. Thus it
implements an integer security level, which has useful values of zero to
two. At level zero, the system functions as always - as if the module were
not present at all. Zero is the default level, but the level can be raised
(but not lowered) by writing the new value to /proc/seclvl.
At level one, a number of actions become disallowed, including:
- Tracing the init process.
- Modifying an immutable file.
- Anything involving raw I/O to a device.
- Network administration tasks.
- Changing the user ID of a process.
- Loading or unloading modules.
- Writing directly to a mounted block device.
- Writing to /dev/mem or /dev/kmem.
- Changing the setuid or setgid bits of a file.
At security level two, a few additional actions are prohibited:
- Changing the system time - but only if you are trying to set it
- Writing to any block device, whether mounted or not.
- Unmounting a filesystem.
The "secure level" patch is thus a way of raising the bar for any potential
attacker. At the higher levels, even a process with root privileges cannot
make certain kinds of changes to the system. Normally, higher levels are
forever; the only way to lower the secure level is to reboot the system.
Note, however, that this module allows the administrator to include a small
back door by specifying an executable that, when run, causes the secure
level to be reset to zero. This feature may be useful for administrators
who are converting a system over to secure level operation. Leaving the
"emergency reset" option enabled permanently would be dangerously
Comments (4 posted)
Writing books about the Linux kernel is hard. The subject matter is vast,
complex, and highly technical. It also is very much a moving target;
today's kernel book becomes obsolete in a short period of time. So kernel
authors have to pick their subject matter carefully, time things well, and
enjoy their fifteen minutes of fame before somebody merges a patch and
their words begin the inevitable slide into obsolescence.
The latest kernel book to hit the shelves is Linux Kernel
Development by Robert Love.
The goal of this book is perhaps best expressed by Andrew Morton in the
foreword. He notes that kernel development has become increasingly complex
as the kernel grows and scales to larger systems. That complexity
increases the functionality and performance of the kernel, but it comes
with a cost: the kernel is harder to understand than it once was.
I believe that this declining accessibility of the Linux source
base is already a problem for the quality of the kernel, and it
will become more serious over time. Those who care for Linux
clearly have an interest in increasing the number of developers who
can contribute to the kernel.
The purpose of this book is to help developers get to where they can make a
Linux Kernel Development covers a lot of ground. There are chapters
on process management and scheduling, how system calls work, interrupt
handling (but not device drivers in general), delayed work mechanisms,
locking and mutual exclusion, timers, memory management, filesystems and the
block layer, the page cache, kernel debugging, and more. This book,
however, is just over 300 pages long, so it necessarily does not cover any
of these topics in any great depth. Thus, for example, you will see what
each of the inode_operations methods is, but there is little
information on how to write one. Linux Kernel Development is a
starting point which will prove useful to any developer trying to get up to
speed with one or more kernel subsystems. Completing that process,
however, will still require setting down the book and diving into the
That said, this book is truly a good starting point. After having perused
the text on a particular subsystem, the reader will have enough background
to be able to make sense of the source much more quickly than before. The
presentation is clear, the writing is enjoyable to read*, and
the information is accurate and useful.
Linux Kernel Development belongs on the shelf of any developer who
is interested in kernel work.
One small complaint that one might make is that it is hard to figure out
just which version of the kernel this book covers. The fine print on the
back notes that it covers 2.6. Of course, the book was published in
September, and now, at the end of November, the 2.6 kernel has not yet been
released, so that statement is not entirely accurate. A suitably attentive
reader can find places where the current kernel diverges from the text of
this book - the listing of struct inode lacks the i_cdev
field, for example. Kernel books will always tend to be like that,
however; they are only completely accurate when they are out of date.
Mr. Love appears to have timed things pretty well with this one;
the differences between the text and the current development kernel are
minimal - so far. For the time being, Linux Kernel Development is
the best description of the structure and API of the 2.6 kernel available.
[Disclaimer: your reviewer is the co-author of a Linux Kernel book which
could be seen as competing with Linux Kernel Development, though he
sees the two as being entirely complementary. Buy Both.]
Though sprinkled with rather more footnotes that your reviewer
might have preferred...
Comments (5 posted)
If you have spent enough time working with development kernels, you may
well have experienced the joy of a system panic which brings the system to
a complete halt. Depending on the nature of the problem, you may find that
the only information on what has happened is to be found on the system
console. At that point, you may be reduced to trying to transcribe an oops
listing by hand - if you are lucky. It may be that the information you
really need has scrolled off the screen and is no longer available.
A useful tool for situations like this is kmsgdump; a version for
2.6.0-test9 has just been announced. This
patch, which includes a scary amount of assembly code, does nothing until
the system panics. At that point it jumps in and dumps the kernel message
buffer to a diskette or parallel port. Later, when your system is running
again, you can look over the output at leisure - or forward it on to
somebody who knows how to interpret it. No more pen and paper required.
Comments (3 posted)
The promised update of the LWN.net
Driver Porting Series
is now complete; all of the articles should be
current with the 2.6.0-test10 kernel. This series now consists of 37
articles covering changes in almost every kernel interface of interest to
driver programmers. More content may be added in the future, but, with
luck, another massive updating (for 2.6, anyway) won't be necessary.
Comments (2 posted)
Patches and updates
Core kernel code
- Len Brown: ACPI 2.6.
(November 20, 2003)
Benchmarks and bugs
Page editor: Jonathan Corbet
Next page: Distributions>>