![[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 Linux History Letters All in one big page See also: last week's Kernel page. |
Kernel developmentThe current development kernel release is 2.5.1, which was released on December 16. Linus has designated it as an intermediate release, so that the patches can be smaller again. The block I/O work is ongoing, however, and Linus isn't much interested in putting in anything else at this point. The current stable kernel release is 2.4.16. Marcelo released the second 2.4.17 release candidate on December 18. If all goes well, this prepatch could turn into the real 2.4.17 release. It would not be surprising if another iteration were required, however. On porting 2.4 bug fixes to 2.5. As work continues on the stabilization of the 2.4 kernel, a great many bug fixes are being generated which are also applicable to 2.5. It turns out, however, that Linus is not interested in those bug fixes at this time. His focus is getting core changes (such as the block I/O work) into the tree; the 2.4 bug fixes are seen as a detail which can be filled in later. Linus's desire to get the big changes in place is understandable, but there are a couple of problems with this approach. One is that some people who want to run 2.5 kernels need some of the bug fixes; but the real threat is that, by the time Linus gets around to looking at the fixes, it will prove hard to get them all in. They will be numerous, some will be hard to merge (as a result of all the big changes), and others may simply fall through the cracks. Dave Jones, while muttering "I'll regret this later," has decided to help out. To that end, he is putting together a set of kernel patches of his own. They are built to apply against current development prepatches, but include the interesting bug fixes from the 2.4 series. These "dj" patches will serve as an accumulator for simple 2.5 bug fixes; when Linus is ready to apply these fixes, they will already be in a nicely organized form and should go in easily. The current patch is 2.5.1-dj3. Future LWN kernel pages will include the latest "dj" patch with the others at the top. Tracking 2.5 API changes. In hopes of having some documentation around, Andreas Bombe has posted a list of 2.5 API changes so far. It's in a highly terse form, but it gives an idea of where to look. It turns out that Randy Dunlap is also maintaining a list of 2.5 changes on the web. What does it mean to signal everybody? Andries Brouwer recently asserted that, according to the latest version of the POSIX standard, Linux does not handle signaling quite as it should. If the kill() system call is given -1 as the process ID, it's supposed to signal every process that the calling process has the right to touch. According to Andries, that includes the calling process itself. So he sent in a patch to implement that behavior, and Linus applied it to see what would happen. What happened is that a number of people complained. A number of commands, including killall5 and some versions of shutdown, are unprepared for the fact that they might signal themselves. Users accustomed to doing "kill -9 -1" commands were surprised to see their shells die. In the end, Linus backed off the change: Note that I've reverted the kill(-1...) thing in my personal tree: so far I've gotten a lot of negative feedback, and the change doesn't seem to actually buy us anything except for conformance to a unclearly weasel-worded standards sentence where we could be even more weasely and just say that "self" is a special process from the systems perspective. The interpretation of standards can be a fun game. The scheduler conversation continues. At one point, a question was directed to Linus asking why he wasn't seemingly worried about new schedulers for 2.5. The answer, it seems, is that he's not concerned. Fight it out. People asked whether I was interested, and I said "no". Take a clue: do benchmarks on all the competing patches, and try to create the best one, and present it to me as a done deal. He seems to think that it's an easy problem, and he would rather not have to deal with the details. Linus also let slip that, rather than worry too much about scheduler overhead, he might increase the clock interrupt rate to 1khz on the x86 architecture. A faster clock will increase scheduling time (because the scheduler is called more often), but can also improve interactive feel. This comment suggests that Linus is not thinking about putting in the "tickless clock" patch anytime soon. On the proper way to do memory pools. Last week's LWN Kernel Page talked about the new "memory pool" subsystem that had been merged into 2.5.1. Since then, a bit of a debate has come up over whether mempools are really the right solution to the problem. The problem in question, of course, is that of ensuring that kernel subsystems that have to be able to allocate memory can always do so. Ingo Molnar's mempool implementation solves this problem by setting aside a pool of memory which is large enough to meet the maximum expected requirement. Mempools sit on top of the existing kernel memory allocators, and use those allocators to create, at the outset, a pool of the necessary size. An alternative approach was posted by Ben LaHaise back in May. Ben's approach implements memory "reservations" in the memory allocators themselves, rather than adding a new layer. There is a real advantage to doing things this way: memory which is kept in the reservation can be put to other uses until it's needed. As long as the reserved pages can be freed instantly, there is no harm in allowing them to be used. Memory contained in mempools, instead, can not be used for any other purpose. The reservation scheme has some disadvantages of its own. Putting reservation logic into the low-level memory allocators increases the complexity of a critical piece of code. It also makes it hard to set up pools of large (more than one page) objects - which is where the allocation problems tend to be the most severe. But the truly fatal flaw for reservations may be the simple fact that the patch was not ready at the right time; Ben admits that the first cut at the patch was not ready for prime time. But, he says, with most patches currently being ignored he is not all that motivated to go make a better one. Other patches and updates released this week include:
Section Editor: Jonathan Corbet |
December 20, 2001
| ||
Copyright © 2001
Eklektix, Inc., all rights reserved
Next: Distributions