Thoughts on 2.6.34

71
So, as most people will have heard, the 2.6.34 kernel was released on May 16. Back in February, I was predicting a mid-May release, so I hit it almost exactly. That says nothing about my prediction skills, though (which are horrible) and a lot about how the kernel development process is going. It has become a very predictable, nearly boring affair.

The cycle itself is highly predictable: kernel releases are routinely 10-12 weeks apart with little variation. This is a big change from the Good Old Days, when the 2.3 kernel was in “feature freeze” for over a year with no visible progress toward a release being made. We, as a community, have figured out how to create a predictable development cycle with little in the way of surprises. Getting there took a combination of discipline, experience, and improved tools, but now we have all three.

Feature sets are still less predictable; a day or so into the 2.6.35 cycle, I cannot really say what will be in that release, despite the fact that much of the new code is already staged in the linux-next tree. One of the headline features of 2.6.34 – the LogFS flash-oriented filesystem – came as a surprise to many. LogFS had been under development for years, sometimes with support from the CE Linux Forum, but it went below the radar for some time until its author decided it was ready. But, beyond LogFS, there was little about 2.6.34 that was truly surprising.

2.6.35 may be similar. There will certainly be improvements to a number of subsystems and a lot of new drivers. We may get a new subsystem for infrared controllers, and the fanotify API (meant to provide hooks for anti-malware scanning software) may finally be merged. With some luck, we will see some important code from the Android kernel make its way into the mainline; if this effort succeeds, it will be the result of a lot of work by a lot of people and some support from the Linux Foundation.

But I predict that there will be nothing truly earthshaking in 2.6.35. No new schedulers, no massive code reorganizations, and no surprising new features. What we’ll see, instead, is the ongoing, predictable improvement of the Linux kernel. If I’m wrong (remember what I said about my prediction abilities), you can give me grief at LinuxCon, which will be happening right about when 2.6.35 is due.

Andrew Morton once famously predicted that the patch volume would have to drop sometime soon because we’d have to actually finish this kernel someday. When he made that prediction (2.6.14), a typical release had about 4,000 changes. Now anything under 10,000 seems slow. So, clearly, we have not finished yet – but might that day be coming? I don’t expect it to happen anytime soon. Even if the world were unchanging, we would have a lot of work to do just improving today’s kernel. In a rapidly-changing world, we’ll continue to need a rapidly-changing kernel too. So there will be lots of changes in our future, many of which may be exciting indeed. In the mean time, perhaps we can enjoy a relatively calm (northern hemisphere) summer.