• 

• Archives

  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007

• Categories

  • weather
• Entries RSS

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: 20% [?]

I fell a little behind on the weather forecast pages, sorry for that. I plead that I was vacationing with the in-laws and would have gotten into serious trouble had I gone too near a keyboard. Anyway, things are caught up now.

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.

Popularity: 55% [?]

On May 3, Linus announced the release of the 2.6.26-rc1 prepatch and the closure of the merge window for this development cycle. So now we know what will be in 2.6.26, which, I predict, will be released sometime around the beginning of July.

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.

Popularity: 50% [?]

The 2.6.25 kernel has been released at last by Linus Torvalds. The plan had been to get it out a week or so ago, but a couple of stubborn problems prevented that. A marathon debugging session by Ingo Molnar turned up the last show-stopper on April 15, and the final kernel came out shortly thereafter.

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.

Popularity: 100% [?]

I got around to updating the forecast pages for the 2.6.25-rc8 prepatch. At this point things are getting close. My guess is that there will be one more prepatch (-rc9) sometime in the near future and the final 2.6.25 release sometime around the U.S. tax day festivities. Such as they are.

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.

Popularity: 53% [?]

• Jonathan Corbet

  

  Jonathan is the executive editor at LWN.net, co-author of Linux Device Drivers, and a Linux kernel contributor.

  Linux Weather Forcast