![[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 Letters All in one big page See also: last week's Kernel page. |
Kernel developmentThe current development kernel release is 2.5.5, which was released on February 20. It incorporates a fair number of changes since the last prepatch, including a bunch of ALSA fixes, more VFS work from Al Viro, a number of USB updates, some big NFS server fixes, and the first (small) bit of merging from Rik van Riel's virtual memory work. The latest patch from Dave Jones is 2.5.4-dj3; it is caught up to 2.4.18-rc2 and 2.5.5-pre1, and adds a number of small fixes as well. The current stable kernel release is 2.4.17. The 2.4.18 release is getting closer; Marcelo released the second release candidate on February 18. Alan Cox's latest patch is 2.4.18-rc2-ac1; it adds version 12f of the reverse mapping VM, an address space accounting system, IBM's JFS journaling filesystem, and a number of fixes. Other recent 2.4-based kernel trees include 2.4.18-rc1-shawn6 from Shawn Starr (adding rmap, the new IDE code, and the XFS filesystem), and Michael Cohen's 2.4.18-pre9-mjc2, which adds no end of stuff. For the 2.0 users out there, David Weinehall has released 2.0.40-rc3, which adds one fix to the previous release candidates. The beginnings of the rmap merge. Rik van Riel's reverse mapping virtual memory implementation was examined on this page one month ago. As of this writing, that patch is still only available for 2.4 kernels; that is a situation that Rik plans to fix soon. Meanwhile, some small parts of the patch have begun to find their way into the 2.5 series. The patch that Linus included in 2.5.5 is the part that reduces the size of the page structure. The kernel maintains one such structure for every physical page in the system, so its size matters. The patch submitted by Rik (containing mostly work by William Lee Irwin and Christoph Hellwig) shrinks struct page with a hashed page wait queue scheme, the merging of a couple of fields, and the removal of the virtual pointer on systems that do not need it. The hashed wait queue code was discussed with the rest of the rmap patch back in January. Of course, now that it is in the kernel, William Lee Irwin has come out with a new version based on "operator-sparse Fibonacci hashing." William posted a brief explanation (with an important correction) on how it works: In my own opinion, this stuff borders on numerology, but it seems to be a convenient supply of hash functions that pass chi^2 tests on the bucket distributions, so I sort of tolerate it The removal of the virtual pointer is a different sort of optimization. That pointer holds the virtual address (in kernel space) for the physical page. It is needed on systems with high memory since that memory, by definition, does not have a static kernel-space mapping. Most systems, however, do not have high memory. For low memory, the kernel virtual address of a page is easily calculated, so a dedicated virtual is wasted. Thus its removal. This patch does not go near the core of the rmap VM, of course, but it is a step in that direction. Rik does plan to start submitting the rest for inclusion before too long - once he has a working 2.5 kernel on his system again. The shared page table patch by Daniel Phillips has also been covered on this page. Several versions of this patch have been released over the last week (here's the latest announcement). The patch has some distinct advantages: memory is saved through the sharing of page tables, and the fork() system call can happen in as little as 1/5 the time. On the other hand, sharing page tables seems to bring in no end of complicated locking problems, especially when pages are being swapped out. As Linus puts it: The only problem is swapout. And "swapout()" is always a problem, in fact. It's always been special, because it is quite fundamentally the only VM operation that ever is "nonlocal". We've had tons of races with swapout over time, it's always been the nastiest VM operation by _far_ when it comes to page table coherency.
This problems will get worked out, but it won't be surprising if the shared page table patch doesn't get into the kernel right away. The net gods are not entirely without mercy. To understand this, one need only look at the unpleasant CML2 flamewar on linux-kernel, which was brought to a none-too-soon end when the mailing list went down. This fight begins to look like the interminable devfs battle, which only ended (sort of) when Linus included devfs into the 2.3 development series. Many of the points in the most recent fight (i.e. use of Python) have been seen before, and we stopped reporting on them a while back. There were a couple of interesting arguments that came out this time around, though, that are worth a look. They strike at the core of how kernel development is done. It all started with this note from Eric Raymond on the kbuild list. Dirk Hohndel, says Eric, was going to "have a chat with Linus" about the new kbuild scheme and Eric's new CML2 configuration subsystem. Eric, of course, is frustrated that CML2 has not yet been integrated into the 2.5 kernel, and he was hoping that Dirk's talk with Linus could help make things happen. The reaction to this move was fierce - it was perceived as an effort to circumvent the normal linux-kernel peer review and pressure Linus directly. Herein lies one of the interesting questions: just what are the appropriate ways of trying to get a patch into the kernel? It is not uncommon to try to push Linus; for example, Andre Hedrick's transparent efforts to get users to complain about the IDE patch gave the appearance (at least) of being highly effective. It's not clear if the problem was accepting Dirk's offer to talk to Linus, looking for feedback on the kbuild list (rather than linux-kernel), or something else. Then, there are those who criticize the CML2 work because it is a single, large patch. The kernel way of doing things, it is said, is to evolve the code in small, simple steps that everybody can scrutinize and see are correct. See, for example, Alexander Viro's posting on the subject. Mr. Viro does practice what he preaches, having massively reworked the virtual filesystem layer through hundreds of small patches. But must all kernel development be done in baby steps? It's hard to imagine introducing ALSA in tiny pieces. Andrea Arcangeli's VM rewrite went in as one big chunk - in a stable series at that. Netfilter was not introduced as a set of incremental patches. CML2 represents a change in both configuration and implementation languages; how does one make that kind of change gradually? The evolutionary approach to development clearly makes sense much of the time, and it may yet be the best way to fixing the configuration subsystem. But there are times when exceptions need to be made. Some people criticize Eric's code for changing the way configuration is done - their claim is that the first version of CML2 to be integrated should make no user-visible changes. Others complain that Eric has failed to implement desired changes, such as the splitting of global configuration information into smaller, local files. Satisfying both camps is bound to be hard (thus Eric has encountered the violence inherent in the system). This is a case where small patches help: each step can be considered on its own merits and has fewer problems with conflicting goals. Still, nobody insisted that the first ALSA patch look exactly like the old OSS drivers. Eric's case is also hurt by the fact that a number of people seem to not like him for one reason or other. His presentation of himself as a "hacker of social systems" while he is having such trouble with the kernel development social system doesn't help. And the simple fact is that most people who work with kernel code configure and build kernels every day and don't have a great deal of trouble with the process. There is a real technical discussion of CML2 and its merits going on, and some version may yet get into the 2.5 kernel tree. But the path to that conclusion does not seem entirely clear now. Other patches and updates released this week include:
Core kernel code:
Development tools:
Device drivers
Filesystems:
Kernel building:
Miscellaneous:
![[packet handling]](http://open-source.arkoon.net/kernel/kernel_net.png)
Networking:
Section Editor: Jonathan Corbet |
February 21, 2002
| ||
Copyright © 2002
Eklektix, Inc., all rights reserved
Next: Distributions