The 2.6.27 merge window closes
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.