Zack's Kernel News

2.6 Kernel Heats Up

Every once in awhile, someone is blown away by how much work is done on the Linux kernel. Recently, Jeff Garzik was the one. With Linus Torvalds using BitKeeper, there's a lot of flexibility in what numbers you can look at. Jeff looked at the Changeset numbers over the course of the day following the 2.6.9 release, and found 850 of them, along with 3,383 revisions. Those are big numbers. If instead you make each ChangeLog entry the unit of measurement, and go by releases rather than absolute time, you see a very interesting breakdown. First of all, unlike previous stable series, the 2.6 kernel appears to be heating up rapidly, not cooling down. This is due to the change in development philosophy, essentially doing away with the strict stable/development type trees. While the first five kernels after 2.6.0 averaged about 1,100 patches each, the next 4, ending at 2.6.9, averaged about 2,500 a piece. The first five kernels after 2.6.0 averaged 225 contributors. The next 4 averaged about 390. My guess is that development will continue in 2.6 until 2.7 opens up. Then the 2.6 pace will slacken, but a true push for pure stability will not occur until 2.8 looks immanent. Linus and Andrew seem to have decided that they don't like the long periods of apparent stagnation that come with a stable series; and the mass of developers apparently agrees with them.

Version Numbers

Linus Torvalds has taken a lot of heat for some versioning blunders he's committed in the recent past. The 2.6.8.1 release raised a lot of hackles, as did his decision to put out a 2.6.9-final kernel, followed by a 2.6.9 kernel that differed from the "final" version. Both of these decisions broke kernel hackers' scripts all over the world, and a number of developers have protested. While they were at it, they also protested the arbitrary distinction between -pre<$> releases and -rc<$> releases. Linus has freely admitted the recent blunders, explaining them as the result of his own dissatisfaction with the current versioning system. He'd really prefer a 4-digit numbering system like 2.6.8.1, but finds that very ugly. The -pre, -rc, .1, -final<$> mechanisms are ways he's tried to avoid that ugliness. It hasn't been a success, but now it looks as though he's going to drop all the rest and just use -rc<$> for inter-version releases. For the next `development' series, assuming he sticks with the decision he made after 2.5.8, there will be no -rc<$> or any other suffix, but just 2.7.1, 2.7.2, and so on. Linus' reasoning back in April 2002 was that development kernels were by definition `pre' releases.

XBox Port

A Linux port to the XBox is underway. This would be no different than any other Linux porting project, except for one little twist: it's impossible even to begin to boot Linux on an XBox without circumventing the hardware restrictions. Actually, there is another twist, but this one is more common: doing a Linux port might violate the DMCA. Now, Ed Schouten says that since the Linux port is being done for the sole purpose of writing interoperable software, it is covered by the Section 1201(f) Reverse Engineering exception of the DMCA. Whether such an argument can stick is a case for the courts to determine. But even without DMCA issues, the fact that you have to alter the hardware to get Linux on the XBox at all is a big strike against. Some see this as a case of porting Linux to a non-existent platform. Other folks have no problem with the port. Linus Torvalds, commenting on the whole idea back in July 2003, felt that an XBox port was a good idea, though he wouldn't consider it for inclusion in the official kernel until it became more widely adopted. And one reason for his hesitation was the politics of hacking on closed hardware.

Info

The Kernel Mailing List comprises the core of Linux development activities. Traffic volumes are immense and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls that take on this impossible task is Zack Brown. Our regular monthly column keeps you up to date on the latest discussions and decisions, selected and summarized by Zack. Zack has been publishing a weekly digest, the Kernel Traffic Mailing List for several years now, reading just the digest is a time consuming task. Linux Magazine now provides you with the quintessence of Linux Kernel activities straight from the horse's mouth.

Braille Terminals

Linux has supported Braille terminals for a long time and has incorporated over a dozen braille-related patches of the past two years. Mario Lang, working on the brltty driver, recently managed to hook up a keyboard directly to his Bluetooth-enabled braille display, creating a fully wireless interface to his system. Dealing with scan-codes and other keyboard-related complexities offered a few stumbling blocks, but in the end, the solution turned out to be to use uinput to pipe the keyboard input directly from user-space into the kernel, where the keyboard would already have been configured. Meanwhile, Samuel Thibault has been working on support for the Visiobraille braille terminal (TVB), and has found an implementation that is even better than the drivers shipped for Microsoft OSes. After solving a particularly thorny problem with serial flow control, Samuel has made patches available for 2.4 and 2.6. Samuel has been working in this area for some time. Back in 2003 he developed a way to allow braille terminals to scroll back, the way regular virtual terminals commonly do. Samuel also developed patches to allow braille terminals to go blank and remain blank even during typing. This feature is to protect the privacy of the user. Samuel also does other console-related work, and work on sound card support.