|
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. |
Valerie Henson, with assistance from Rodrigo Rubira Branco, Yong Cai, and Brian Twichell, has announced ebizzy, a new performance evaluation tool. The tool generates a workload similar to that of a web server and reports on the number of transactions per second.
Valerie says the tool is particularly useful for comparing memory management patch performance and for threaded applications. In addition to Linux, ebizzy also compiles under Solaris.
Rik van Riel recently announced the creation of a new Japanese language kernel newbies list [1]. In his announcement, Rik said he hopes this will encourage Japanese developers to get started in kernel development.
On the accessibility front, Samuel Thibault has extended braille keyboard support in the kernel to allow keyboards with up to 10 dots. Before now, Linux only supported braille keyboards with up to eight dots.
Because braille dots are binary (either up or down), Samuel's patch means Linux will be able to support braille fonts with 1024 distinct characters, instead of the 256 characters afforded an eight-dot font.
Adrian Bunk removed APUS support from the kernel. The code supporting the PowerUP Amiga had been listed as broken for two years, and the removal process had begun. Adrian's patch was aimed at removing the final remnants of the code, which was not debated.
Adrian also posted patches to remove the eepro100 driver because it has been replaced by the e100 driver. However, Auke Kok replied that the e100 driver did not yet work on the ARM architecture, and he asked whether Adrian could delay removing the code until that support could be added. Auke guessed this would be done some time before 2.6.25. Adrian agreed with this suggestion and said he would resend the patch in the early -rc releases of that version.
Andi Kleen patched NUMA to be marked as experimental. He added a message saying that this code should only be used for kernel development and might in any case cause boot failures. He'd done some tests that revealed a lot of problems and felt it was important to alert potential users to the danger. No one raised any objections to his patch, so presumably NUMA will be marked experimental in upcoming kernels. At the same time, in an unrelated post, Subrata Modak announced an initial release of some NUMA test cases, integrated into the Linux Test Project (LTP). Hopefully these will help bring NUMA to a more stable state.
Jiri Slaby has submitted a driver, listing himself as the maintainer. The driver adds support for Syntek's stk1125, stk1135, and stkdcnew webcams, which come built-in on some laptops. He based his work on a similar driver by Nicolas Vivien. Andrew Morton had some technical suggestions, but nothing to indicate that the patch was not acceptable.
Ondrej Zary has submitted a patch supporting IdealTEK URTC1000 touch screen controllers. Daniel Ritz had some suggestions, which Ondrej adopted immediately and submitted as a new patch. Daniel approved the new version and sent it along to Dmitry Torokhov to pass up to Linus Torvalds.
Joe Perches has posted a script that automatically identifies the appropriate people to whom a patch should be submitted on the basis of the directories modified. No more combing through the MAINTAINERS file - this script does it for you! The script analyzes the patch to see what directories it affects and then sifts the MAINTAINERS file for the "file pattern" field, which describes the directories associated with a given project. Then the script reports the official contact information for the matching project.
But wait! You say there is no "file pattern" field in the MAINTAINERS file? No problem - Joe also submitted hundreds of patches adding the appropriate fields and directories to each entry. This saves a lot of slogging through the sources and could have some exciting effects. Besides making life easier for the average kernel hacker, Joe's script and accompanying infrastructure will make it easier for newcomers to contribute. Anyone coming to the kernel for the first time, with no knowledge of who is working on what or where to submit patches, will not have to worry. They will be able to focus entirely on writing their patch and not on the question of what to do with the patch once it is written.
Some developers wondered whether it was necessary for the kernel sources to support compilation by any version of GCC earlier than 4.0. Adrian Bunk first posed the question, and several folks spoke in favor of supporting older GCC versions. Russell King said that GCC 4.0 was still not stable enough on the ARM architecture and GCC 3.4.3 was much more reliable. Russell also pointed out that 3.4.3 was faster than 4.0. And Kyle McMartin added that the same arguments held true for the PARISC architecture and in some cases, GCC 3.4 generated better code than 4.0. Chris Wedgwood added that some users were working on old systems with old versions of GCC who still wanted new kernels.
Adrian said that it would be possible to continue to support earlier GCC versions on the architectures that needed it, and not the rest of the source tree. He pointed out that the kernel currently supported half a dozen compiler versions and that eventually it would be necessary to reduce that number. Adrian also pointed out that probably few kernel developers actually needed any compiler other than 4.0. Linus Torvalds said it is the users testing the kernel who needed to be considered. He said, "If we make it harder for people to test kernels, we're going to lose. So no, I vote for not cutting off old GCC versions unless it's absolutely fatal."
Adrian argued that there was a possibility that certain kernel problems would be directly related to which GCC version was used to compile it and that, in those cases, the problem might languish and never be fixed - support for the offending compiler would probably not be actively removed from the kernel, nor would it be fixed although officially that GCC version would still be "supported." But Adrian acknowledged that it was clear from the discussion that it was not yet time to consider removing support for old versions. He indicated that he would attempt to track GCC version-related bugs and point them out to the list.
Evgenly Polyakov announced a new distributed storage subsystem (DST) that allows the creation of arbitrary filesystem "nodes" that nest across a network to form a single directory tree. The subsystem transparently handles a variety of network protocols (and potentially even different operating systems), depending on what is available on the system hosting a given node.
The subsystem also provides some failover and recovery support. No special tools are needed for this subsystem - once the code stabilizes and is adopted into the kernel, the subsystem will just work. It does seem as though Evgenly's distributed storage subsystem code will go into the kernel at some point because there is a lot of support for it.
| INFO |
|
[1] Kernelnewbies Japan: http://lists.kernelnewbies.org/mailman/listinfo/jp-kernelnewbies
|