Looking forward to 2.6.29
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.