|
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. |
In recent days Greg Kroah-Hartman has made several attempts to remove DevFS from the 2.6 tree. He first tried posting a patch to just whisk it out entirely, but this seemed too aggressive to some folks, especially folks who use and rely on DevFS every day. So Greg next tried posting a patch to merely disable DevFS, with a plan to remove it if no one squawked too loudly. This also seemed too extreme for many. Finally, Greg created ndevfs, a "nano" version of DevFS, that could replace the full version and hopefully satisfy the hardcore DevFS users. But now it turned out Greg couldn't live with this compromise himself, and he decided to abandon the patch. He just didn't feel a dynamic /dev belonged in the kernel. This, however, left the problem unsolved. At one point, Greg said, "devfs is not needed, it's wrong, and it will be removed from the kernel."
One of the most interesting aspects of the whole debate is the fact that no one says much about Greg's own (and the official) DevFS replacement, udev, although Greg created udev specifically to replace DevFS. It seems that DevFS, in spite of its critics, is something no one else could effectively replace, even after many attempts, so its final removal may not be accompanied by the introduction of an equivalent tool.
Richard Gooch, the creator of DevFS, came under fire almost immediately upon introducing the tool. His coding style was quite different from other kernel programmers, but he insisted that his was the correct way. His purpose of creating a dynamic, in-kernel replacement for the /dev directory was also extremely controversial right from the start, especially with folks like Alexander Viro, maintainer of the VFS. For years, the flames darted here and there, Alexander complaining about problems in Richard's code, and Richard accusing Alexander of not clearly identifying those problems.
Eventually Linus Torvalds apparently settled the issue by accepting DevFS into his official tree. For a few brief moments, it seemed Richard had finally won the debate, until it turned out that Linus had his own ideas about what DevFS should do. A number of these ideas, in fact, ran counter to Richard's own intentions for DevFS. Meanwhile, more and more users began to rely on the tool for their daily use, and it developed quite a following. But many top kernel programmers continued to feel that this was one of the worst decisions Linus ever made. One day, Alexander made his pronouncement that DevFS contained "unfixable races," and this judgement has stuck with DevFS ever since. Eventually, seeing the writing on the wall, Richard gave up on the entire project and vanished from public kernel development. Eventually Greg, one of DevFS's harshest critics, took over the project in order to one day retire it, but he has apparently found that more difficult than he imagined.
If you are a regular reader of this column, we encourage you to the visit the Kernel Traffic web site for more kernel news. The Kernel Traffic site archives and indexes newsletters, letting you browse by topic, date, or contributer.
The site opens with this preamble from Zack:
"Kernel Traffic is a group of newsletters, but it is also one particular newsletter that covers some activities of the linux-kernel mailing list, the main mailing list for Linux kernel development. On it, Linus Torvalds, Alan Cox. and a lot of other amazing programmers from around the world share patches, argue about implementation details, discuss the news of the day, and generally make history.
Because of the sheer volume of linux-kernel (sometimes up to 3000 messages per week), and also the highly technical nature of some of the discussions, it's impossible to cover everything, or even all of the most interesting threads (and if it were possible, it would take about as long to read as the actual list). If you really want to follow Linux development, there is still no substitute for reading linux-kernel yourself.
My name is Zack Brown. I came to Linux in `94 when I had finally had enough of DOS; Since then, I've enjoyed watching Linux grow from an unbelievably great system into the stuff of ballads and legends"
The folks at Novell have created a new open source kernel debugger (NLKD), and they will present a paper on it at the Ottawa Linux Symposium. But kernel developers have not exactly thrown open their arms to welcome this project. There are several existing open source kernel debuggers (KGDB and KDB), that Novell didn't really examine when producing their own. Also, it seems that the existing debuggers have some features that are missing from NLKD. Also, the Novell debugger only offers patches against a particular vendor-specific kernel, making it more difficult for others to test. Those who did test NLKD gave lukewarm reviews. On the other hand, as some have pointed out, this is a step in the right direction for Novell as a company, and various developers have already begun to give pointers and suggestions on how to improve NLKD.
Meanwhile, Linus Torvalds has for a long time been suspicious of kernel debuggers, saying they promote sloppy debugging practices. He feels the best way to debug the kernel is to understand its operations, examine the source code, and deduce the problem. Using a debugger, he says, allows bugs to be found without really promoting a clear understanding of the code, thus making it more likely that sloppy fixes will be submitted. A huge number of kernel developers disagree with him on this, however, and at times he's expressed a willingness to compromise on the debugger issue.
Micha Piotrowski has written a small script to help users compose bug reports. He calls the script ORT, for "Oops Reporting Tool." ORT gathers various data about a running system, including oops information, and sends this data to the linux-kernel mailing list or to a specific maintainer.
Micha created this tool because many people don't have enough time, patience, or knowledge to create a proper bug report on their own. All too often, bug reports posted to linux-kernel fail to include sufficient detail about hardware or software, or even which kernel was running at the time.
ORT has been favorably received by various kernel folks, some even suggesting it could be included in the main tree; but there have been a few criticisms as well, most notable being ORTs reliance on root privileges. But these technical problems seem well on the way toward being sorted out.
For the final story this month, I would like to join many others in wishing John Hall, author of Programming Linux Games (and not to be confused with Jon "Maddog" Hall), a full recovery from his cancer. John was recently diagnosed with metastatic melanoma. He's written a blog about his ongoing battle at http://overcode.yak.net/3.
Linus Torvalds's git version control tool seems to be fulfilling its promise of becoming one of the most incredible examples of open source development since the Linux kernel itself.
Linus also continues his tradition of making a design decision that many people loudly object to until they understand it. The prevailing example in recent weeks has been the propagation of tags. git allows users to tag versions of the repository with a particular short name, like 2.6.12. This tagged version, being easier to refer to than the SHA1 hash value, is then also easier to remember and use. It's a standard version control device, but in git's case, repository tags are considered private. Person A may add all sorts of tags to their repository, and if person B clones that repository, none of those tags will come along with the clone unless person A specifically informs person B of each one.
Many folks object to this, because it means that some of the history of a given repository is being lost. Person B's repository is no longer an exact clone of person A's repository. This just seems to violate the whole principle of version control. But Linus argues that, in a distributed development environment, allowing tags to propogate by default through repositories would mean that any tags created by any developers for their own needs would therefore trickle back into the main kernel, causing potentially massive numbers of useless tags.