When to release 2.6.28?
December 12, 2008 | Comments Off
The 2.6.28-rc8 kernel prepatch is out. That means that the final 2.6.28 release must be getting close. I once heard Linus say that he would never hold a kernel release past -rc9 regardless of the situation; there comes a point where you have to send it out into the world and get on with development. In this case, though, 2.6.28 appears to be stabilizing nicely. The list of regressions is getting fairly short. So this kernel will truly be ready to go soon.
That leads to an interesting question, though: when should this release actually happen? One would not normally be concerned about releasing a new kernel just before the holidays; if anything, that would just give a few extra days for any remaining issues to be found and fixed before they cause trouble for more people. But one should remember that the merge window - the two week period in which major changes for the next kernel cycle are accepted into the mainline - traditionally opens just after the final release. So a pre-holiday 2.6.28 release would imply that the merge window would happen over the holidays. Their geeky reputation notwithstanding, the majority of kernel developers are not going to be that thrilled about having to get their 2.6.29 changes merged in the middle of holiday celebrations.
So Linus is considering delaying the 2.6.28 release until after the holidays - either that, or releasing before but holding the merge window closed for a couple of weeks. That idea appeals to a number of developers, but it risks running into another problem: linux.conf.au begins in mid-January. Quite a few kernel developers will be there, and dealing with merging in the middle of a conference is almost as bad as doing it over the holidays. Last year’s LCA happened during the merge window, and there is a strong preference to avoid repeating that experience.
So we may see a pre-holiday release after all - either that, or it may happen right around the new year. We’ll probably not know for sure until Linus pulls the trigger.
Trying to fit in releases and merge windows around real world events like this is a bit of a pain. But it is certainly a lot nicer than having release dates determined by (1) product schedules, or (2) the simple fact that the software is not yet ready. In fact, having a development process that works well enough to allow for this kind of worry is a luxury, all things considered.
Popularity: 17% [?]
2.6.28 takes shape
October 24, 2008 | Comments Off
Linus Torvalds released 2.6.28-rc1 and closed the merge window on October 23. So we can now see what will be in the 2.6.28 kernel. Once again, it looks like an active development cycle with a lot of new stuff for Linux users.
Memory management patches are notorious for taking a long time to get into the kernel. So it is not surprising that Rik van Riel’s scalability patches were years in the making. That code has been merged now; it should improve performance on any system with heavy memory loads. Also merged was Nick Piggin’s vmap rewrite which makes things run quite a bit quicker on multiprocessor systems.
Every development cycle brings in dozens of new device drivers, and 2.6.28 is no exception. One thing that is a bit different this time around is the inclusion of Greg Kroah-Hartman’s staging tree into the mainline. This tree contains device drivers that, for one reason or another, are not considered to be up to the usual quality standards for kernel code. They have been merged because it has been observed, over and over again, that code in the mainline tree improves much more quickly than out-of-tree code. Some of the staging tree drivers have been under development for years without getting up to a reasonable quality level; once in the mainline, some of them, at least, will improve radically over the next few months.
Ultrawideband is a GHz-range radio protocol which can be used for networking, or for number of other applications. One of those is wireless USB - connecting USB devices without the actual wire. 2.6.28 will have support for both ultrawideband and wireless USB. Much of this work was done at Intel, so, naturally, most of the supported devices tend to be made by Intel as well.
The 2008 Kernel Summit, held in September, decided that one of the first steps toward better tracing was the creation of a low-level interface for getting tracing data out to user space. 2.6.28 will have the new trace buffer code, along with a number of other tracing-related improvements.
The “ext4dev” filesystem is now called ext4. The removal of the “dev” suffix is the developers’ way of saying that this filesystem is stabilizing and getting close to ready for production use. I expect the developers to say that it’s truly ready sometime in the next couple of development cycles - in the first half of next year. Meanwhile, the next-generation btrfs filesystem has been queued into linux-next and will probably be merged into the mainline for 2.6.29 - though it will not be production-ready for some time after that.
In some ways, the most promising addition for 2.6.28 is the Graphics Execution Manager, a low-level memory-management module for graphics processors. The addition of GEM marks the beginning of the end of the long process of bringing Linux graphics into the present age. With luck, in-kernel mode setting will be merged for 2.6.29 and the job will be close to done - at least, for graphical chipsets made by cooperative vendors.
There is a lot more than that in 2.6.28, of course; it’s hard to describe over 7,000 changes in a single post. But those are the highlights. Now it comes down to the long task of stabilizing all of those changes for a solid 2.6.28 release, which will probably happen in January, 2009.
Popularity: 38% [?]
The 2008 kernel summit
September 12, 2008 | Comments Off
The agenda for the 2008 kernel summit has been posted. The summit is an annual, invitation-only event which is typically attended by 70-80 developers. It is a rare opportunity to bring part of the kernel community together for focused discussions on topics which affect the kernel as a whole.
What sorts of topics are those? In recent years, the summit has tended to emphasize process-oriented issues - those are the kinds of discussions which are hardest to have over electronic mail. So, for example, there will be a discussion on just when device drivers should be merged. There is a weak consensus that getting drivers into the kernel early is a good idea, but there are hazards there too: a premature driver merger can freeze a bad user-space API in place, and the UVC webcam driver, merged very late in the 2.6.26 cycle, brought a security vulnerability with it. So the real answer to “when should drivers be merged?” has yet to be found; we’ll see if the summit discussion gets any closer.
One of the reasons why the kernel process works as smoothly as it does is that many of its subsystems are strictly independent of the others. A developer working on sound drivers need not worry about breaking the memory management code, for example. Some subsystems have strong ties with others, though; for example, i2c drivers end up being core subcomponents of video drivers, hardware monitoring subsystems, and quite a bit more. In cases like this, making changes which don’t break other parts of the kernel can be hard; there is a session this year dedicated to figuring out ways to make that interaction have more smoothly.
Other process-oriented discussions include a session on tools, kernel quality (a perennial kernel summit topic), documentation, helping new developers join the community, and the organization of the kernel summit itself.
There will be some more technical sessions as well. The interaction between filesystems and the block layer is one of those; there is a lot happening in the filesystems area currently, and that has implications for how the higher-level code works. Boot-time tools - currently maintained independently by each distributor - will be discussed with an eye toward unifying some of that code. Improving suspend and resume - another longstanding topic - will be back this year. And, of course, there is no escaping a discussion on tracing, an area where Linux should excel but where things have not, yet, come together as they should.
Finally, for the third year, the kernel summit will hold an election for the Linux Foundation’s Technical Advisory Board (TAB). Six of the board’s ten slots will be filled this year; as of this writing, there are ten candidates (including five incumbents). This time around, the election has been made part of the joint reception with the Linux Plumbers Conference, which will allow more people to participate in the process.
It’s worth noting that, among many other things, the Linux Foundation has helped with the organization of both the kernel summit and the Plumbers Conference. There have been few developer-oriented events in the United States in recent years; I’m actually looking forward to going to a conference which doesn’t involve customs formalities. Thanks to the Linux Foundation (and the many other people involved) for helping to make these events happen.
Popularity: 46% [?]
The 2.6.27 merge window closes
July 29, 2008 | Comments Off
On July 28, Linus Torvalds released the 2.6.27-rc1 prepatch and closed the merge window for 2.6.27. That means we now know what will be in this kernel, which will probably be released sometime in October. Recent cycles have featured a lot of internal cleanup and relatively few new features, but 2.6.27 will reverse that trend somewhat. Linux users will see a lot of new things here.
First, though, let your author brag for a moment. Linus said that one of his favorite changes this time around is the BKL pushdown work, much of which was done by, well, me. Linux users won’t see the results of this work directly, though it should lead to better scalability and cleaner code internally. The removal of the big kernel lock is long overdue; in 2.6.27 we’ve made some significant steps in that direction.
Tracing continues to be a hot issue. There are a number of tracing-related patches in 2.6.27, though none of them will, on their own, make Linux tracing competitive with DTrace (though things are happening toward that goal). The ftrace framework provides relatively simple tracing which is especially well suited to the needs of realtime developers. The “tracehook” mechanism makes the placement of static trace points in the kernel easier - and it comes with an initial set of static points. mmiotrace lets developers watch memory-mapped I/O activity - a useful reverse engineering tool.
On the scalability front, the lockless page cache code has been merged after an especially long gestation period; this code will make things significantly faster, especially I/O-heavy workloads on multiprocessor systems. There’s also code intended to make Linux run well on 4096-processor systems - just a little bit bigger than this year’s laptops, but it won’t be long.
There’s the usual pile of new device drivers in this kernel. The ones people may notice the most is a large set of video “webcam” drivers called “gspca,” which has finally made its way into the mainline. As of 2.6.27, Linux supports almost every webcam model on the market.
The future of storage increasingly looks to be dominated by solid state (”flash”) devices. Traditional filesystems, intended for rotating storage, are not necessarily well suited to the different needs of solid-state storage. It is not at all clear which filesystem we’ll be using on flash media in the future, but it is clear that Linux will have a few good options. One of those is UBIFS, which will be present in 2.6.27.
Other significant developments include hardware-based data integrity support for the block layer, multiqueue networking (needed for good wireless support, checkpoint and restore support for Xen virtual machines, a new ISDN stack, delayed allocation support for ext4 (making that filesystem almost feature-complete), a new suspend and hibernate infrastructure, a set of system call extensions which will allow user-space programmers to avoid common race conditions, kexec jump, MMU notifiers, and much more.
All told, it has been an eventful release cycle. Sufficiently eventful, in fact, that Linus worries a bit (in the -rc1 announcement) that our release cycles have gotten too big. That may well become a topic for the next Kernel Summit, which will be held immediately prior to the Linux Plumbers Conference in September. In the mean time, the kernel developers will be busy getting all of this code into shape - and, of course, working on more interesting new stuff for 2.6.28.
Popularity: 78% [?]
2.6.26 at last
July 14, 2008 | Comments Off
Linus Torvalds released the 2.6.26 kernel on July 13 - somewhat later than most people had expected. At a full three months, this development cycle took longer than some others; that is especially surprising given that the number of patches merged and new features added is somewhat less than we have seen in recent development cycles. Still, at over 10,000 changesets, this is not a small release.
As always, I recommend that people wanting to know all about what’s in this release head on over to the KernelNewbies 2.6.26 page.
The new feature list for this kernel is huge. But there is a lot of good stuff there. One of my favorites is the incorporation of the kgdb debugger for the x86 architecture. Linus has been resisting the addition of an interactive debugger almost since the very beginning; he believes that such tools lead developers to focus on symptoms rather than understanding the underlying problem. But one of the things that makes Linus who he is is that he can, with effort, be convinced to change his mind. And so the developers who have long patched in kgdb from outside have finally gotten their point across: development tools help to make a better tool. Don’t expect Linus to use kgdb anytime soon, but he has at least let it into his kernel.
Now attention turns to the 2.6.27 development cycle; Linus has already started merging patches for this release. One of the more interesting things to watch will be whether the merge window process goes more smoothly this time around. 2.6.27 will be the first kernel cycle for which the linux-next tree was in full operation, so, in theory, much of the integration work has already been done. If linux-next has done its job, this merge window should come together with relatively little pain. See this article and this one for more information on the evolving role of linux-next.
And stay tuned: I’ll be back in about two weeks with a summary of what will be in the 2.6.27 kernel.
Popularity: 68% [?]
-
Jonathan Corbet
Jonathan is the executive editor at LWN.net, co-author of Linux Device Drivers, and a Linux kernel contributor.
Linux Weather Forecast