![[LWN Logo]](http://old.lwn.net/images/lcorner.png)
![[LWN.net]](http://old.lwn.net/images/kernel.png)
|
|
|
 Sections: Main page Security Kernel Distributions Development Commerce Linux in the news Announcements Back page All in one big page See also: last week's Kernel page. |
Kernel developmentThe current development kernel release is 2.4.0-test1. Linus has returned from his travels, but has only begun to surface on the development lists. One imagines that, after three weeks, he had a bit of a pile of mail witing for him... One sign of his presence, however, is the existence of a 2.4.0-test2 prepatch, in its eighth revision as of this writing. It contains a great many fixes, including "all the unquestionable ones" from the "ac" series that Alan Cox ran in Linus's absence. That series continued over the last week, culminating in 2.4.0-test1-ac22. The "ac" patches have stopped since Linus's return, of course. For the scoop on what's going on, there's no better place to go than Telsa Gwynne's diary: It's rumoured that Linus is back. I am hoping this means I shall see Alan for more than a ten minute lunch break in the near future. Unfortunately, I caught him collecting the Linux 8086 code earlier today, with gleeful mutters. Oh dear. The current stable kernel release is 2.2.16. The 2.2.17 prepatch is up to 2.2.17pre5; Alan is still working on stabilizing things and is thus not including much except obvious bugfixes. One change that did slip through in 2.2.17pre3, however, has raised some questions. It seems that only root can load new keyboard maps now. This change blocks users from doing a number of things they might otherwise like to do, such as loading a Dvorak keyboard or putting useful stuff on the function keys. Or, of course, putting the control key back where Nature always intended it to be. The problem, of course, is that somebody who can remap keys can bind them to perform some rather less useful functions. One could, for example, make the period actually send "rm -r /*", something the unsuspecting user will likely have cause to be unhappy about. The threat of this sort of obnoxiousness was enough to motivate the kernel developers to cut off the ability to change keymaps without privilege. Requiring root privileges to load keymaps puts the issue into the area of administrative policy. Those who want to enable random keymap loading can set up a setuid program to do so; others might choose to limit the loadable keymaps to those found in a specific directory. Now the ability to impose that sort of control exists; in previous kernels it was not possible. Dueling memory management algorithms. One of the more interesting aspects of the 2.4.0-test1-ac22 patch is that it came in two flavors. One incorporates Rik van Riel's latest memory management code; the other, instead, includes Andrea Arcangeli's "classzone" patch. The two have been in disagreement for some time over which approach was best; Alan was perhaps hoping to see some definitive results one way or the other as a result of people trying both out. If so, the initial results look to be disappointing. A few people have posted comparisons, but there has been little that has clearly favored one approach over the other. There are some vague references to classzone providing better interactive performance, but with the van Riel patches yielding better throughput overall. The problem of coming up with a truly optimal Linux memory management algorithm appears to be still unsolved. This issue needs to be dealt with before 2.4.0 can come out; the memory management hackers appear to have some work ahead of them yet. Reiserfs-3.6.9 has been announced. This version adds a new hashing scheme along with a port to a later 2.4.0-test1-ac kernel. Meanwhile, Hans Reiser continues to complain about his treatment in linux-kernel, since his filesystem has not yet been merged into the kernel. Here's an example of what has been going on, complete with the "ReiserFS FUD list." The kernel developers are (mostly) trying to make a real show of deciding on reiserfs based solely on technical considerations, not on the behavior of its leader. He is, however, making that hard to do. The Direct Access File System (DAFS), an attempt to speed file serving in local area networks, was announced this week. DAFS appears to have its roots at Network Appliance, but is now being supported by an industry consortium that includes Red Hat and VA Linux Systems. The details are still scarce - the consortium plans to have a protocol proposal together later this year. But it has the look of a very simple protocol aimed at enabling fast transfers in a low-latency, low-loss situation. More information can be found on the DAFS Collaborative web site. The presence of Red Hat and VA Linux, of course, implies that a Linux implementation of this protocol can be expected sooner rather than later.
IBM to release LVM technology. IBM has posted an announcement to some of the development lists stating that it will donate its logical volume management (LVM) technology to the Linux community. This donation currently seems to be limited to a white paper on the technology; there's no word on when more might be forthcoming. There has also been no word on what this implementation would offer above the existing LVM implementation in the current development kernel series. Watch out for gcc 2.96. The latest versions of the gcc compiler - such as the one found in Red Hat's "rawhide" distribution, will not compile a working kernel. As often seems to happen with new versions of the compiler, new optimizations have been introduced which break assumptions in the kernel. Things will eventually be ironed out; until then, stick with an older compiler for kernel building. Other patches and updates released this week include:
Section Editor: Jonathan Corbet |
June 22, 2000
| ||
Copyright © 2000
Eklektix, Inc., all rights reserved
Next: Distributions