|
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. |
With the recent push toward supporting Japanese speakers in kernel development, Greg Kroah-Hartman has also been encouraging Japanese translations of kernel documentation. In response to this, Keiichi Kii recently translated the "SubmittingPatches" guide, one of the most useful documents for anyone getting started with kernel development, into Japanese. There are several other docs that change fairly infrequently that Greg suggested would be useful to non-English speakers, including "CodingStyle" and "SubmittingDrivers." A full set of translated kernel docs no doubt would be useful, as would translated config text, error messages, and code comments. These first steps hopefully will encourage others to participate in a more general translation effort and in efforts to solve various problems associated with making translations as accessible as possible to the speakers of a given language, while keeping all other languages from appearing to clutter up the source tree.
Recently, some folks started increasing the size of the CodingStyle file to include best practices and advice on how to write readable code. This led to a debate in which Linus Torvalds made it clear that he didn't want to enforce a rigorous standard in areas in which there was a lot of room for individuality. He wanted CodingStyle to be as small as possible, containing only the big issues such as making sure to use proper indentation. Other issues, like the idea that parentheses in printk() should not be used, Linus considered minor stylistic issues that shouldn't be forced on anyone. In fact, he considered the existing CodingStyle file already to be too bogged down with details, when its purpose should be to explain more general principles.
Alexander Viro also made the point that no matter how draconian a set of coding guidelines becomes, it will always be possible for someone to adhere to them strictly and still write bad-looking code.
The folks favoring the expanded CodingStyle file are now working on a companion document that contains only suggestions, so CodingStyle can focus on what should be enforced in the kernel. Linus is fine with that approach, so long as the scripts used to check submitted patches for style errors don't end up harassing patch submitters for minor infractions.
Some folks have been interested in either finding work with companies doing Linux development, or else discovering some other way to get involved in a professional capacity. Over the course of discussion on linux-kernel, Greg Kroah-Hartman posted his own estimates of company participation in Linux development: http://lkml.org/lkml/2007/10/14/241.
The top five Linux development companies on Greg's list are somewhat predictable: Red Hat, IBM, Linux Foundation, Novell, and Intel.
Thanks to Adrian Bunk, there is always a lot of code coming out of the kernel, and when other people try to take code out, chances are that Adrian has already been there. For example, Robert P. J. Day recently attempted to remove some old APUS support from the PowerPC architecture; Adrian said he already had a patch waiting in the wings.
The APUS code has actually been listed as broken for more than two years, and some APUS code has already been taken out, as of kernel 2.6.23. Robert had found the remaining bits via a script he'd written, which identifies dead code in the kernel sources.
Adrian successfully removed several I2C drivers: the i2c-ixp2000.c, i2c-ixp4xx.c, and scx200_i2c.c code, which had no one to speak up for it. Some of his efforts this time around were still a bit premature. For example, he tried to take out some legacy I2C drivers that have already been replaced. The problem with this came when Jean Delvare pointed out that the replacements had not yet been fully adopted by various platforms, specifically the PowerPC. Those platforms would have to be updated to use the new drivers before the old ones could be removed.
Adrian also made another in a long series of attempts to get rid of the eepro100 driver. This driver has long since been replaced by the e100 driver and marked for extermination, but as Jeff Garzik and Auke Kok previously explained, the e100 still has problems that make it difficult for eepro100 users to switch over.
Plus, David Acker, who is working on bringing the e100 driver up to snuff, has had to devote his attention to a number of other projects, which has been slowing down his e100 efforts. Furthermore, some e100 bugs are difficult to test, making the whole project more of a slow grind. In the face of everyone's desire to get the old eepro100 driver out, though, David said he'd do his best to step up his efforts. For the moment, however, Adrian's code cleanup will still have to wait.
As always, many new drivers and other features were added to the kernel (or at least submitted) since last issue. For example, Vince Kim recently tried applying LZO compression to CramFS and discovered it resulted in a significant performance gain, at the cost of a significantly larger binary for the driver.
Zhang Wei has also been developing a driver for the Freescale MPC8540 DMA controller, and he recently posted his work, along with a new entry in the MAINTAINERS file listing himself as the maintainer. This controller is found in printers and other devices.
More laptops can reveal status information via their panel lights. Stephen Hemminger has written a new driver (apanel), that improves on earlier work by Jochen Eisenger. The apanel driver gives control over the panel lights on some Fujitsu laptops.
Samuel Ortiz has written code supporting the Compaq ASIC3 multi-function chip used in PDAs.
Bryan Wu posted a driver to support AD7877-based touchscreens and another to support AD7142-based joysticks.
Gilles Gigan wrote a driver supporting the watchdog timer found in IEI single-board computers. These watchdogs are a hardware mechanism that lets the computer reboot automatically in the event of a crash. Giles based his work on a related driver by Scott Jennings.
Darrick J. Wong has been working on a driver to support the temperature and power sensors in IBM System X servers supporting PowerExecutive, including the x3550, x3650, and x3655, as well as some HS20 BladeCenter systems.
Tsugikazu Shibata has started putting kernel releases on his public Google Calendars. On the calendar web page, go into the Add menu and select Add a friend's calendar," then add these addresses for the various trees: linux.release.history@gmail.com, linux.release.candidate@gmail.com, linux.release.mm@gmail.com, and linux.release.stable@gmail.com.
Gabriel Craciunescu noted in the MAINTAINERS file that the TLAN network driver mailing list was subscriber-only. Alan Cox also posted a patch to mark the geode-related mailing lists as subscriber-only after he was unable to follow up on some bugs. Randy Dunlap also marked the kbuild list as subscriber-only after his post was held pending moderator approval.
Later, Sam announced he'd created a new kbuild list on vger, called linux-kbuild, that was not moderated or subscriber-only. Because Sam didn't have the list of subscribers from the other list, folks must transfer over to this new list on their own, but he did update the MAINTAINERS file to show the new list instead of the old one.
| INFO |
|
[1] Kernelnewbies Japan: http://lists.kernelnewbies.org/mailman/listinfo/jp-kernelnewbies
|