Zack's Kernel News

Replacing BitKeeper?

Kernel development is still being done primarily with BitKeeper, and that won't change any time soon, but the free alternatives are getting better and better. The tla, or arch, program may actually have a better design than BitKeeper, and it may ultimately support better features; but it is not yet able to scale to the awe-inspiring size and speed of Linux kernel development. Andrea Arcangeli has become the main tla advocate among kernel developers, but Linus Torvalds has begun to flame freely whenever BitKeeper alternatives are mentioned. David Roundy, primary author of the darcs version control system, avoided the carnage by announcing a darcs repository of the Linux kernel sources. This is a major achievement for any revision system because of the sheer size of the kernel source history, let alone the speed at which new patches are added. The fact that darcs has done this is a significant milestone. The scaling problem has not been solved, though - David affirms that there are real speed issues. But the existence of a kernel gateway, similar to the CVS and Subversion gateways, into the BitKeeper repository allows kernel developers to give much-desired feedback to David. These gateways will almost certainly be the way BitKeeper is ultimately replaced. Only when the vast majority of kernel developers have migrated to tla, darcs, or some other distributed alternative, will Linus finally give way and abandon BitKeeper. It is important to remember that most of the work being done today on distributed revisioning systems was inspired by Linus' choice to use a proprietary tool in the first place. It could be argued that his stubbornness is fuel for those projects.

Udev Documentation

Every once in awhile a big developer puts out a solid chunk of documentation. Recently Greg Kroah-Hartman and Alexander Viro did this independently of each other. Greg, who has been maintaining the udev replacement for DevFS for some time now, finally created a web page for the project, at http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html. Until now there hasn't been one. The site includes a lot of information for the curious, including a general udev primer, as well as a comparison of udev and DevFS, and links to specific udev HOWTOs for various distributions. Alexander, the longtime Virtual Filesystem maintainer, wrote a HOWTO on cross-compiling the Linux kernel. This can be somewhat intimidating if you don't do it on a regular basis, and Al took a lot of the scare out of it, by presenting step-by-step instructions, which he has posted to the linux-kernel mailing list.

Supporting Old Compilers

Timothy Miller has started a heated discussion about the support for older compilers. He asked why so much effort was being put into supporting older GCC versions - if folks wanted to upgrade their kernel, wouldn't they also be willing to upgrade their compiler? Matti Aarnio pointed out that the latest greatest compilers weren't always the greatest on architectures other than x86. Folks compiling Linux for SPARC and other hardware tend to be more conservative and stick with a compiler that they have learned to work. Linus Torvalds said that newer compiler versions generally were slower, buggier and generated worse code. To him for a long time the only reason to upgrade GCC was literally C++ support, while basic C support was getting worse and has only improved a bit lately. Others, however, would like to see more people using current compilers, giving the GCC developers more feedback, helping them improve.

Info

The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching ten thousand messages in a given week, 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 to take on this task is Zack Brown. Our regular monthly column keeps you abreast of the latest discussions and decisions, selected and summarized by Zack. Zack has been publishing a weekly online digest, the Kernel Traffic newsletter for over five years now. Even reading Kernel Traffic alone can be a time consuming task. Linux Magazine now provides you with the quintessence of Linux Kernel activities, straight from the horse's mouth.

More on Versioning

Linus Torvalds, in addition to renaming the kernel from Zonked Quokka to Woozy Numbat in 2.6.10-rc1, is now trying to address some of the versioning complaints that folks have been leveling at him lately. To reduce the madness of x.y.z.w-pre-rc-final naming variations, Linus has decided that 2.6 will just have -rc releases between point releases. No more -pre, no more -final, no more mess. At least until tomorrow. As the naming system stabilizes, however, the 2.6 code itself continues to change at an ever-increasing rate. The 2.6.9 release had 3549 patches, more than any other 2.6 kernel except 2.6.0. The number of developers is also skyrocketing to over 400 for each of the last two releases, while averaging about 250 for the rest of the 2.6 series. Not only is no 2.7 fork visible on the horizon, but the entire idea of a development series may have gone out the window. It may be that, for the future, stability will be the province of developer forks like Alan Cox's -ac series and distributions like Red Hat, Debian, and Tinfoil Hat Linux; while new features will continue to be added to the main-line at breakneck speed.

GPL Violations

A rash of apparent GPL violations, loophole attempts, and misunderstandings have been popping up. It is hard to guess whether this is a seasonal thing, a temporary trend, or the way things will be from now on. Between October and November, about 6 companies were accused of GPL violations on the linux-kernel mailing list. Some of these accusations were mainly the result of misunderstandings, as in the case of Adrian Bunk's suggestion that the drivers/char/rocket.c contained two conflicting licenses: the GPL and Comtrol Corporation's non-free license. Theodore Ts'o, the author of the code, affirmed that this was just a mistake, and quickly got Comtrol's agreement to remove their license from the file. The tougher cases seem to involve companies looking for loopholes. One company apparently distributes source code to older versions of its product, claiming that the newer versions are identical to the older versions although the newer versions contain some proprietary code. They apparently also refuse to distribute product updates to anyone who exercises the GPL's right to re-distribute software. These may not turn out to be GPL violations, but if true, they are certainly ugly. Although it is rare for a company to use GPLed code and just ignore the GPL, at least one company - according to Marcus Metzler - is apparently rejecting outright any request for the source.

Heat Monitoring 0n 64-bit

Zwane Mwaikambo, working on Intel-donated hardware, posted a patch that "adds support for notification of overheating conditions on intel x86_64 processors. Tested on EM64T, test booted on AMD64." Andi Kleen asked if the code had been tested in actual overheating conditions, and Zwane replied that no, he'd only just forced the event to trigger. Andi also had some pretty invasive criticisms about the patch, with the overall sense that a different approach might be better. He remarked, "sorry for telling you late, but I also only realized it later". They talked about deep dark magic and the physics of temperature drops for a few posts, and Zwane went off to rework his patch.

KProbes for PPC64 architechture

Ananth N. Mavinakayanahalli has ported the KProbes debugging mechanism to the PPC64 architecture, shortly after the initial port to the 2.6 kernel by Prasanna S. Panchamukhi and David S. Miller. Prasanna later also ported KProbes to the X86_64 architecture, with help from Andi Kleen. A lot of the KProbes work so far has been to facilitate the general porting task, so we can look forward to support for other architectures as time goes by. Kprobes is a friendly debugging tool, attempting to coexist peacefully with other in-kernel debugggers It is able to trap at almost any kernel code address, allowing developers to collect debugging information without disrupting the running system.