Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release is 2.5.1. Linus's 2.5.2 prepatch is up to 2.5.2-pre6. This prepatch contains more block I/O work, of course, though that effort seems to be winding down - for now. So this prepatch includes a number of other things, including a merge of many of the fixes from the "dj" patch series, Al Viro's namespace patch (described in the March 1, 2001 LWN kernel page), some scheduler work from Davide Libenzi, a USB update that includes beginning support for USB 2.0, and a number of other things.
One of those "other things" is a 'new and anal' kdev_t type. kdev_t, the internal kernel representation for device numbers, has traditionally just been the user-space dev_t in disguise. It is now defined as a structure as a way of finding all kernel code which treats kdev_t as a simple number. Even proper code needs editing, however, since the macros which manipulate kdev_t have changed. As of -pre6, there is a lot of code which still needs work and which, thus, does not compile. The -pre6 prepatch is not for people who are not interested in tracking down these sorts of problems.
The current stable kernel release is 2.4.17, released on December 21. There was some grumbling that the final 2.4.17 patch included a couple of new fixes; Marcelo's policy seems to be that obvious, simple bug fixes can go in even after the last release candidate.
The first 2.4.18 prepatch came out on December 26; it is a large patch with a number of architecture updates.
Other prepatches: Dave Jones's current prepatch is at 2.5.1-dj10. It tracks the Linus prepatches through 2.5.2-pre5, and, thus, does not yet contain the kdev_t work.
Michael Cohen has concluded that the world still needs a 2.4-based development tree. So, he has released 2.4.17-mjc1 to fill that need. It starts with 2.4.17, of course, but then adds Rik van Riel's reverse mapping patch, the preemptible kernel patch, software suspend, Andre Hedrick's IDE work, and more. Despite all that, Michael claims "I'll try to keep this as close to the 2.4.x line as possible."
2.2 users may be interested in 2.2.21-pre2 from Alan Cox.
Scheduler tweaks. The debate on what changes should be made to the scheduler in 2.5 has not yet really happened. Even so, Linus has started merging in tweaks to the existing algorithm, in the form of Davide Libenzi's Time Slice Split Scheduler patch. This patch changes the way the scheduler handles the "dynamic priority" of processes; the result, hopefully, is fairer scheduling with lower overhead.
The Linux scheduler has traditionally handled dynamic priority via a task structure field called counter; the number stored in counter is, essentially, the number of clock ticks left in the process's time slice. By using this count as a priority adjustment, the kernel tries to divide the processor relatively equally among processes that need it; a process which has not managed to use up much of its time slice will be selected over another which has exhausted most of its time.
The new scheduler separates dynamic priority from time slice accounting by replacing counter with two new task structure fields: dyn_prio and time_slice. This change simplifies the time slice accounting in the kernel, and makes it easy to adjust the dynamic priority for other reasons. For example, a small priority boost can be given to a process which has just completed an I/O operation without increasing its time slice.
The new code has been steadily tweaked since its inclusion in the prepatch, mostly through adjustments to the time slice and dynamic priority settings. There have been few complaints, but also few posted benchmark results. And this patch does little to address the difficulties encountered by the current scheduler on SMP systems. Work with the scheduling algorithm is likely to continue for some time.
The kernel development process has been discussed from many angles over the last couple of weeks. Perhaps, at the end of a sometimes difficult year, developers need to ponder on how to make things better. Here's a few things that have come up:
The patch management issue, in particular, is likely to help drive the continuing success of the alternative kernel trees. Increasingly, one or more of these trees is likely to become a necessary staging area where patches can be tried out before finding their way into the mainline kernel. In fact, Linus says that the multiple trees are one of the strengths of the kernel development process for a number of reasons, one of which is patch management.
The Linux kernel is almost alone in its use of multiple trees as part of the development process. Many projects have stable and development branches, but few have multiple trees on either the stable or development side. It will be interesting to see if the multiple-tree idea proves useful enough to spread more widely in the free software development world.
The new kernel build implementation remains a topic of interest. Eric Raymond has sent out a the state of the new config and build system message stating that everything was ready to go whenever Linus is. Keith Owens, meanwhile, has released kbuild 1.12 for the 2.5 kernel. There remains one little problem, however: the new kbuild takes about twice as long to execute a full kernel build. Not surprisingly, the kernel developers are not entirely enthusiastic about this state of affairs. They wait on kernel builds every day and have little taste for a change that makes things far slower.
Keith's response to the complaints is essentially this: the new kbuild fixes a number of problems, especially with regard to handling of dependencies, that exist in the current kbuild system. Correctness comes first, with performance to follow. Keith believes that he can fix the performance problems, fairly quickly, but only after the kbuild code has been integrated into the kernel. Until then, he is busy enough just managing the patch and keeping it current with kernel releases.
Linus, you have a choice between a known broken build system and a clean and reliable system, which is slightly slower in mark 1. Please add kbuild 2.5 to the kernel, then I will have time to rewrite the core programs for speed. Mark 2 of the core code will be significantly faster.
There has been no word from Linus. In the view of many kernel developers, however, who have not generally had trouble with the existing build system, the new kbuild should not be merged until the performance problems have been dealt with. Keith has already made some steps in that direction with a new design for the management of the data used by the kbuild process.
Other patches and updates released this week include:
Section Editor: Jonathan Corbet
January 3, 2002