• 

• Archives

  • March 2009
  • January 2009
  • December 2008
  • October 2008
  • September 2008
  • 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

Sharp-eyed observers may have noticed a slightly unusual patch which was merged into the mainline kernel on March 17. It’s a new mascot for the kernel; among other things, this image is shown at boot time for a number of configurations. For many a year, the mascot has been Tux the penguin. For 2.6.29, though, Tux will be taking a break while “Tuz” steps in.

Tuz is most emphatically not a penguin. Those who look closely will see that the kernel’s stand-in mascot is, instead, a Tasmanian devil wearing a penguin mask. Tuz began his career as the mascot for the 2009 edition of the linux.conf.au conference, held in Hobart, Tasmania. So why is Tuz moving on to the mainline kernel?

It turns out that Tasmanian devils are currently endangered by an especially nasty form of communicable cancer. The lca2009 organizers decided to dedicate the event’s traditional charity auction to the cause of helping research into this disease. This auction surpassed everybody’s expectations, raising some AU$40,000 for the campaign to save the devil.
In the process, it also treated attendees to the sight of Linus Torvalds shaving Bdale Garbee’s beard.

After returning home, Linus decided to help raise awareness of the Tasmanian devil’s plight by bringing in Tuz for a kernel cycle.

There are a lot of reasons why developers create open source software. Beyond the fact that it’s simply fun, many of us are motivated by a desire to make the world a better place. The strong support in the development community for causes like the Tasmanian devil shows that this desire to improve the world goes beyond the creation of great, free software. It’s something we can all be proud of.

(See the “Save the Tasmanian Devil” site for more information on this effort and how to help).

Popularity: 84% [?]

On January 10, Linus Torvalds released the 2.6.29-rc1 prepatch and closed the merge window for the 2.6.29 release. At some 8800 changesets (so far), 2.6.29 looks to be a large development cycle. That said, this kernel cycle will have a relatively small list of exciting new features for most people - but the items on that list are big ones.

First and foremost for many people will be the addition of the Btrfs filesystem. Btrfs is intended to be the next-generation filesystem which, conceivably, could last us for the next 10-20 years. The filesystem found in 2.6.29 is not, yet, that filesystem, though; Btrfs remains under heavy development. There will certainly be bugs, the user-space tools are not polished, and the possibility of on-disk format changes is real (though diminishing). Nobody should be expecting to use Btrfs for any data they care about for the next year - at least.

Given that, why did Btrfs go into the mainline now? The answer is simple: an in-mainline Btrfs will certainly approach production-readiness more quickly than it would outside of the mainline. Once a project like this gets merged, its code becomes more readily available to far more users and developers; as a result, it gets more widely tested and more people contribute fixes. So expect the (already quite fast) development pace set by Btrfs to increase significantly.

The faster pace set by in-tree code is also the motivation behind the “staging” tree, which is now in its second mainline development cycle. This tree accepts drivers which are considered to be below the normal standards of quality expected for kernel code. Many of these drivers are, frankly, scary in how they are written. But many of them enable hardware which is otherwise unusable on Linux systems. The hope is that bringing them into the mainline will help to get them up to proper quality standards more quickly while, simultaneously, freeing users and distributors from the need to patch those drivers in separately. Early experience shows that staging-tree drivers do, indeed, see fixes for a lot of problems which have remained unfixed for years previously. Some staging tree drivers of note this time around include the Comedi data acquisition framework, drivers for Ralink 2860 and 2870 wireless interfaces, and a number of drivers used by Google’s Android platform.

Yet another bit of almost-ready code is the kernel mode-setting (KMS) patches. This work fixes what is now seen as a longstanding design mistake in how video adapters are supported on x86-based systems. Many years ago, the XFree86 developers took the approach of programming video hardware in user space - essentially moving the device drivers out of the kernel. This was done because video hardware was complex and nobody knew how to drive it within the kernel without adding huge amounts of kernel code. The result was working support for the X Window System, but at the cost of reduced system stability, confusion over which part of the system was in charge of the graphics hardware at any given time, and the need to run a huge body of complex code (the X server) with root privileges.

Kernel mode setting does away with all of that, moving basic control of the graphics hardware back into the kernel. When this work settles out, we’ll have more solid, better-performing, and more trustworthy 3D graphics support - and it will no longer be necessary to run X as root. This, too, is very new code, though. Potential testers need to approach it with caution, the right hardware (only some Intel adapters are supported, currently), and the right user-space code. Anybody wanting to enable KMS should be sure that they have a version of the X server which is prepared to work with it.

Squashfs was also merged for 2.6.29. It is a compressed, read-only filesystem used in embedded systems and live CD distributions. It has taken a long time for this code to reach the mainline; meanwhile, it has been widely used and packaged by many distributors.

One small, quiet piece of code which went in was a new set of security module hooks which enable the addition of pathname-based mandatory access control mechanisms. This was an important prerequisite for security modules like AppArmor and TOMOYO Linux, which may finally be getting close to inclusion into the mainline.

Finally, one change which users will not see (unless it breaks something) is the massive credential records patch. This code reworks the handling of credentials (the system’s idea of who a given process represents and what capabilities it has), bringing a fair amount of order to this area. It is also a prerequisite for the FS-Cache code - active caching for network filesystems - which may now go in for 2.6.30 or 2.6.31.

Now the stabilization process starts. There’s enough under-the-hood changes in 2.6.29-rc1 to ensure that a surprise or two awaits early testers. Over the next two months, these problems will be found and fixed, setting the stage for a stable 2.6.29 release sometime in March.

Popularity: 77% [?]

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

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

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

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

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

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

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

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

The weather forecast pages are quite kernel centric - that’s the area I know best. There is a user-space page, though, featuring a few important components. Many of those have been revised in recent times:

• 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.

Popularity: 83% [?]

After updating the current conditions to reflect 2.6.25-rc4, I went into the security page and added some introductory text; I’ll probably do this with the other pages as well over time.

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.

Popularity: 78% [?]

The 2.6.25-rc1 prepatch was released on February 10. The -rc1 release, of course, indicates the closing of the merge window and the beginning of the stabilization period for this cycle. So I’ve updated all of the weather forecast pages to reflect what went in and what didn’t, and generally updated it (often by extending potential merge dates into the future - I never promised I actually knew what I was talking about…)

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.

Popularity: 75% [?]

As I predicted, Linus released 2.6.24 just before heading off to linux.conf.au in Melbourne. He’s slipping, though: usually he waits until I’ve gotten on a plane and can’t update web sites before shoving a release out the door. I’m still here, though, so the main Weather Forecast page has been updated to reflect the current state of affairs.

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.

Popularity: 73% [?]

We’re still waiting for the 2.6.24 release, which seems likely to come out near the end of the month - just before linux.conf.au. While waiting, I’ve gone through and made a large number of small updates throughout the forecast pages. The development kernel is at 2.6.24-rc8 - probably the last -rc for 2.6.24. I’ve tweaked other version numbers where appropriate, added links to stories, etc.

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.

Popularity: 70% [?]

This is a relatively slow time of year for kernel development (not too surprisingly), so there have not been a great many updates to the forecast pages. Expect things to pick up in January. Meanwhile, I did catch up to the 2.6.24-rc6 release.

And yes, speaking of January… my prediction that 2.6.24 would come out “around the end of the year” may still prove to be strictly correct, but it was, nonetheless, a bit on the optimistic side. So now I’m saying it will be out in January, which should be safe.

Popularity: 68% [?]

Linus took almost three weeks to get 2.6.24-rc4 out - the 2.6.24 process has, in general, been quite slow-moving this way. Normal practice is to try to get -rc releases out once per week. It only took me two days to update the corresponding forecast page, so I feel like I’m doing pretty well. The Btrfs entry has also seen minor updates - version 0.9 just came out. Things are getting better there, Btrfs almost doesn’t crash when the disk gets full…

Popularity: 67% [?]

Time for a few basic updates, starting with a somewhat belated acknowledgment that 2.6.24-rc2 is out. Now that I’ve caught up, expect Linus to release -rc3 just about any time.

PID namespaces continue to present complicated issues - it’s hard to present a coherent view of the system while simultaneously putting up walls between groups of processes. The result is that the PID namespace code may well not be available in 2.6.24, even though it will be present in the tree. I’ve added pointers to a couple of articles explaining why.

Finally, I added a new section on the TTM memory manager, a piece of code which is a major step toward properly-designed graphics support in Linux.

Popularity: 67% [?]

The first 2.6.24 prepatch is out, signaling the closing of the merge window. So I have gone and tweaked things all over the Weather Forecast pages to match the new reality. The summary on the main page now shows the highlights of 2.6.24, and various other entries have been changed to reflect what happened during the merge window. In particular I quietly changed the predicted merge dates for all the stuff which I thought would get into this kernel, but didn’t. Unless you go to the Wayback Machine, you’ll never know I was wrong.

I also added entries for the controller area network code (to the networking page), Atheros wireless chipsets, and a note (on the user-space page) that glibc will go to GPLv3 sometime soon.

Popularity: 64% [?]

The new GNOME development timeline is up; it predicts a GNOME 2.22 release on March 12. The GNOME entry has been updated accordingly.

The x86 merger has happened, so the miscellaneous topics page has been updated accordingly. While I was at it, I added an entry on KGDB - another attempt to get interactive debugger support into the mainline kernel.

Popularity: 64% [?]

The user space page has been tweaked to reflect Tuesday’s release of of gcc 4.2.2. This is a minor release containing mostly bug fixes; nothing all that exciting to report.

Popularity: 63% [?]

SMACK is a simplified mandatory access control module for Linux. It seems likely at this point that SMACK will have the honor of being the first such module to join SELinux in the mainline kernel. So I added an entry on the security page about it.

Popularity: 63% [?]

A number of people remarked that the Linux Platform Weather Forecast had become rather too large to read comfortably on a single page. So I’ve split it up into several sub-sections. Most of the content is the same, though there are a couple of exceptions:

• I wrote the page as if 2.6.23 were already out, because, as everybody knew, its release was imminent. Well it’s still not out, so the page is a little forward-looking at the moment.

• The user space page includes an entry about glibc.

Popularity: 63% [?]

• The “final -rc release” for 2.6.23 wasn’t, so point to -rc8.
• Added an entry on credential records.
• Added an entry on FS-Cache.

Popularity: 64% [?]

• Jonathan Corbet

  

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

  Linux Weather Forecast