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.

The current prepatch is 2.6.26-rc8; when he posted it, Linus said that it might just be the last one. Given that this development cycle is smaller (in terms of the amount of code merged), I had thought that it would come together a little quicker; thus the “late June” prediction which had appeared on the forecast pages. Well, it’s late June, and we’re not there yet. More worryingly, the length of the regression list is about the same as it has been for the last month or so. My guess is that there will be an -rc9 before it’s all done, but I’ve been wrong before.

I added a few entries to the pages while I was there. HP donated AdvFS, which is a welcome body of code even if it will never be shipped in the mainline kernel in anything close to its current form. The GEM memory manager is interesting: it looks like it will displace TTM as the presumptive memory management code for 3D graphical processing units. That’s a classic example of how the kernel development process can work: TTM embodies a great deal of work, but that work can be quickly pushed aside if somebody comes up with a better way to get things done. This can be hard on individual developers, but it’s good for the resulting kernel. Finally, I couldn’t resist putting in a thing about the BKL-removal work, which is a project I’ve somehow gotten pulled into.

Look for more change once the 2.6.27 merge window opens. I’ll be cleaning out a bunch of older stuff then as well.

Many developers will be pleased by the addition of the KGDB debugger for the x86 architecture at last. For as long as I have been following Linux development, Linus has opposed interactive debuggers; he fears that they cause developers to look at symptoms and miss the true causes of bugs. After all this time, a dedicated group of developers was able to put together a version of KGDB that Linus could stand, though, and so in it went. The merged version lacks some useful features, such as KGDB-over-ethernet, but those can be obtained with external patches and, with luck, will make it into the mainline sometime in the future.

When the OLPC folks made mesh networking work on the XO laptop, they put the bulk of the code into the “Libertas” driver for the XO’s Marvell-based network chip. That code ran into difficulties at merge time because the networking developers thought that the mesh features should be implemented at a higher level where they would be useful for a wider range of devices. So Libertas was merged without mesh networking. Now, though, a more generic mesh networking implementation has found its way into the mac80211 layer. That, too, will be part of 2.6.26.

Other nice features include page attribute table (PAT) support, which should help ease a number of hardware-related hassles. There’s a braille screen reader layer. A lot of containers work has gone in, pushing that capability closer to completion. And so on.

But one thing that is notable about this cycle is that it is relatively small. 2.6.25 finished out at over 12,000 individual changes; 2.6.26, at this point, has some 7500. It would appear that, after two cycles of intensive merging, the developers are slowing down just a little bit. So there’s rather fewer new features this time around. That may lead to a shorter development cycle for 2.6.26 and, perhaps, fewer problems to fix on the way there.

When I predicted that the release would be “around tax day in the US” I came pretty close. Maybe I should do this sort of stuff for a living.

I was talking with one of the developers at the recently-held Collaboration Summit; he told me that 2.6.25 was notable in that it didn’t really have any new stuff that he was excited about. That’s pretty interesting given that this development cycle was the biggest on record: over 12,000 changesets merged from some 1200 developers and almost 370,000 lines of new code. It is true that a lot of this work was internal stuff - making things work better inside the kernel, but not visible to users. That said, there’s still some fun stuff in this release, including:

• The “pagemap” patches. For a long time people have wondered just which processes on their system are using all the memory. The existing tools (primarily “ps”) are not as helpful as one would like for that sort of question. These patches, by Matt Mackall, enable the kernel to provide much more detailed information on memory use; this will be valuable to administrators worldwide.
• The SMACK security module breaks the monopoly on mandatory access control previously held by SELinux. In the near future we’re likely to see more options for the hardening of Linux systems.
• Initial support for kernel-based video modesetting. Conventional wisdom says that graphics support on Linux has been messy for a long time; now it’s getting cleaned up in a big way.
• The Controller Area Network protocol remains interesting to me, though not because I expect to use it in the near future. CAN is a protocol for networking in noisy environments - in a car, for example. It’s how all your gadgets will talk to each other, enabling the system to, say, interrupt your phone call when the forward-looking radar has concluded that you’re about to have an unwanted encounter with the car ahead of you. This code was developed and contributed by engineers at Volkswagen - not normally considered to be a hotbed of Linux kernel hacking. The range of industries which are beginning to understand the benefits of collaborative development is impressive.
• The ath5k driver for Atheros chipsets. This driver comes from our friends in the OpenBSD community, who made the major effort of reverse-engineering these chips. After a lengthy delay while some legal concerns were taken care of, this code has finally made its way into Linux, bringing support for one of the most problematic bits of hardware (though the 2.6.25 driver still has some rough edges). One has to wonder that the recent decision by Atheros to hire an ath5k developer and work toward mainline support for all of its hardware is purely coincidental.

That is just the beginning of the list for 2.6.25. If you want to see the whole list, head over to the always-amazing KernelNewbies changelog, which has all of the details.

So what about 2.6.26? As of this writing, the merge window has not yet opened. That can be expected to happen in the next couple of days. I think I’ll resist the temptation to predict what will go in during this cycle - I’ll get proven wrong too quickly.

Also finally, I got around to doing an entry on UBIFS for the filesystems page. UBIFS is a flash-based filesystem, meant to replace JFFS2 and compete with LogFS. It looks like it is relatively close to being ready; it might just win the race with LogFS for inclusion into the mainline. Time will tell, though; LogFS developer Jorn Engel doesn’t look like he plans to sit still and let UBIFS take all the thunder.

The filesytems page also has an introductory section now introducing the topic and describing the pressures facing filesystem developers.

For those who haven’t seen it, the Linux Foundation has posted a study of the kernel development process written by Greg Kroah-Hartman, Amanda McPherson, and yours truly. For the curious, I’ve also put up development statistics for 2.6.25 on LWN.

• The long-awaited KDE 4.0 release happened in January. This major update of KDE is not quite ready for prime time yet, but it is getting there and the indications are that it’s going to be great.
• GNOME 2.22 just came out. This is a more incremental release, but it still features a lot of interesting new stuff.

• GCC 4.3.0 also just came out. Lots of improvements, but also an ABI change which could cause applications to experience weird crashes on older kernels.

I do still plan to expand this page someday. Meanwhile, those who are interested in the lower levels of user space may want to keep an eye on the first Linux Plumbers Conference, happening this September in Portland, Oregon.

Security has been on my mind as a result of the somewhat embarrassing vmsplice() exploit. This vulnerability has renewed interest in various kinds of technical means for preventing vulnerabilities - stack smashing detection and the like. This is all good stuff, and we should have it. But much of that technology would not have helped in this case; the vmsplice() exploit was a subtle and complex thing.

This vulnerability was not a failure of the kernel’s anti-compromise technology. It was a failure of the review process which allowed code with obvious mistakes into the kernel. Review is the critical, limiting resource for a lot of free software projects, and the kernel is no exception. Reviewing code is hard and thankless work, but the process really does not work without it.

About 9500 changesets were merged for this release - that’s a lot of new code. The pace of kernel development does not look like it will be slowing down anytime soon.

After my upcoming travels, I’ll do a cleanup pass. There’s some old-news topics which can come out at this point, and a few new ones which should certainly be there.

Normally, this would be the start of the 2.6.25 merge window. That will still be the case, but Linus’s travel (and that of many other kernel developers) will likely slow the process a bit. Once things get going I’ll update the pages to reflect the shape of this kernel and what might come afterward.

I also cleaned up a substantial number of rather embarrassing typos. I’m really not illiterate, honest.

Finally, the filesystems page has seen a number of updates, reflecting the large amount of work happening in that area currently. Btrfs is coming along quickly. I’ve added a new entry for unionfs, which has returned from relative obscurity with a big push for inclusion into 2.6.25.

Finally finally, I added a paragraph incorporating some of my statistics to the 2.6.24 discussion. This has been a record-breaking development cycle in a number of ways; even watching it as closely as I do, I find myself wondering how it all actually works sometimes.