|
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. |
Steven A. Falco has added support for the ST M41T65 real-time clock chip. Because this is very similar to the M41T80, which already has a driver, it was decided to just extend the existing driver. Alessandro Zummo and Maciej W. Rozycki both pointed out that this would be best for code maintenance, although if larger changes were needed later, it might be OK to split out the drivers into a common portion and several satellite portions.
Tomas Winkler of Intel announced that he'd modified the iwlwifi driver to support the Wifi Link 5000 and 5100 series adapters. This was very welcome news to Will Simoneau, whose new Sager laptop came equipped with a 5300 card; he helped Tomas track down a bug in the code that Tomas had known about but had been unable to reproduce on his own hardware.
Thomas Renninger wants to introduce an interface to report BIOS bugs to the user. The basic idea is that ACPI, PCI, and other subsystems can introduce BIOS bugs that the kernel has to sanity-check.
Thomas wants to have the kernel log the results of these sanity checks. This way userspace programs would be able to respond better to BIOS bugs, vendors would have an easier time testing, and users would have a better sense of how to proceed when they encountered system problems, as Thomas pointed out.
Andi Kleen was in favor of the general idea and offered suggestions for some implementation changes, whereas Bjorn Helgaas felt the whole thing might be a case of over-engineering.
The work required to maintain all the specific log output would be intense and would also be prone to rapid aging. Andi just wasn't sure the benefits would be worth it. But his misgivings didn't prevent him from offering up a variety of implementation suggestions. So it does seem as though this idea will be going forward.
Following up on a general effort to remove binary-only firmware from the kernel sources, David Woodhouse announced a new git repository for firmware, which will include not only the firmware that has been distributed with the kernel sources, but also any firmware that vendors want to make readily available to Linux users.
Stefan Richter has also been active on the documentation front. He created a new FireWire wiki on ieee1394.wiki.kernel.org to replace the old one from linux1394.org after that one had become overrun with spammers posting their own URLs on the site.
The new wiki is better maintained and, by now, more up to date than the old one.
Ryusuke Konishi announced the NILFS2 filesystem, a new versioning filesystem that snapshots all data continuously. This makes it possible to immediately recover files that have been accidentally deleted or altered. Ryusuke did a lot of work on this project earlier, but because of problems with the coding style, it required a lot of rewriting before he was ready to submit it for inclusion in the main tree.
Although Ryusuke points out that the code is still fairly immature, Andrew Morton is enthusiastic about the project and has included it in his own tree for wider testing. The filesystem is very fast, although as Andrew points out, its speed might diminish over time because it has to handle more and more snapshotted data. Time will tell on that score.
In the meantime, a bunch of other folks started reviewing the code. Andi Kleen asked how stable the on-disk data format was. Presumably the filesystem would only be accepted into the main tree after its format had stabilized; otherwise, Linux would have to support the old format as well. Ryusuke's reply to Andi was that the disk format was "almost stable." He was hopeful that he wouldn't have to make any changes that would harm compatibility with itself. But this too would depend on the feedback he got from other kernel developers and users.
Overall it looks like quite a useful project, with a bunch of interested folks already working on getting it into a mergeable state, although probably it will stay in Andrew's tree for quite awhile before migrating over to mainline.
Rick Jones of Hewlett-Packard has announced PCItop, a new GPLed tool, similar to the "top" system monitor, that reports on the activity running across the PCI bus. Currently, only HP Integrity systems are supported, but Rick has invited anyone to join in and help support other platforms.
Jonathan Corbet has written a nice long document about kernel development from the perspective of employers and the kernel developers working for them. The document was written to be included in the kernel sources, but it might find a home on the kernel.org website as well.
The main point seems to be that learning the ins and outs of the development process and culture will help companies manage their own expectations and get where they want quicker.
As Jonathon puts it in one of the introductory paragraphs, "The kernel's development process may come across as strange and intimidating to new developers, but there are good reasons and solid experience behind it.
A developer who does not understand the kernel community's ways (or, worse, who tries to flout or circumvent them) will have a frustrating experience in store. The development community, while being helpful to those who are trying to learn, has little time for those who will not listen or who do not care about the development process."
Certainly this is true. Countless examples exist of developers trying - in some cases for years - to force their code into the kernel (ReiserFS being a relatively recent example), only to find developers losing interest who could have provided the necessary feedback to get that code accepted.
The document starts off with a general introduction to the value of getting code into the official tree, the various licensing issues, and an explanation of versioning and release schedules.
After that follows a detailed explanation of the "life cycle" of a submitted patch. This part describes the various tools and mailing lists that might be useful to new developers. It then gives a quite detailed explanation of everything a developer would need to do, from idea to implementation to incorporation of code into the tree, including a nifty list of pitfalls to avoid, such as problems surrounding #ifdef usage.
The whole document is really very thorough and forms a very impressive use-oriented snapshot of the ongoing cultural development of the kernel developer community.
Jonathon has given a lot of wonderful texts to the Linux community over the years, and this document is another excellent effort on his part. But also, by incorporating the document into the kernel sources, it becomes a living document that has already received lots of suggestions and changes from folks like Andrew Morton and others.
Read the document online at: http://ldn.linuxfoundation.org/book/1-what-this-document-is-about
