|
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 more than 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. |
Arjan van de Ven from Intel announced the new PowerTOP tool. PowerTOP analyzes everything running on a system and reports on how power is being consumed. With this tool, it's possible to identify a lot of ways to save power on a laptop. Intel's testing showed ways of improving a "typical" laptop's battery life by more than an hour. Regardless of those particular tests, it does seem clear that a tool like this will be extremely useful, both for regular users and for the maintainers of tools that might inadvertently use too much power. Open Source software everywhere can now look forward to receiving patches to lower power consumption. I imagine that whether you run PowerTOP or not, your laptop will start to run longer as software is updated based on this new data.
Adrian Bunk and Wim Van Sebroeck have posted a patch to remove the i8xx_tco watchdog driver. The driver had been scheduled to be taken out in 2.6.22, and its functionality had already been replaced by the iTCO_wdt watchdog driver.
Keith Packard of Intel announced a new 965GM Express Chipset driver produced by that company. As he put it, this chipset "represents the first mobile product that implements fourth-generation Intel graphics architecture. Designed to support advanced rendering features in modern graphics APIs, this chipset includes support for programmable vertex, geometry, and fragment shaders." A bunch of folks were happy to hear this news, and Jeff Garzik said, "Here's hoping that Intel produces a standalone video card eventually, to further take away market share from closed source competitors."
Robert P. J. Day started an effort to update the Documentation/feature-removal-schedule.txt file, so the features scheduled for removal would correspond with the features that should be scheduled for removal. Everyone agrees the file is woefully out of date, but the best way to update it is not clear. One way, as suggested by Stefan Richter, is just to try to remove the scheduled code and then see if anyone complains. The problem with this approach is that it's a bit of work to remove code, and if the only result is that the date of removal is rescheduled, it seems like it would be good to avoid doing all that work in the first place. Which leads back to the idea of updating the feature-removal-schedule.txt file.
It's not clear whether much will come of Robert's information-gathering expedition. Typically, the folks who would be affected by a particular code removal won't notice the debate until someone actually tries to remove it, at which point they'd squawk loudly. It may be that Robert's attempt to find a consensus beforehand is just not workable.
The raw driver has been taken off the list of deprecated kernel features to be removed from the code at some future date. Dave Jones has noted that after repeated attempts to get rid of this driver, it still had a significant user base that didn't seem to be going away any time soon. He posted a patch to take the raw driver off the to-be-removed list and also to change its status in the configuration system to no longer be deprecated.
This last change drew some criticism. Some folks pointed out that the feature should still be listed as deprecated, to prevent it from getting any new users. The problem with this, as Dave pointed out, is that leaving it deprecated would only prompt other kernel folks to think that it had been inadvertently left out of the to-be-removed list.
Those folks would then submit patches to add it back in, and we'd have a circle.
Pierre Ossman said he was going to post a patch listing some MMC drivers as orphaned unless maintainers stepped forward to take responsibility for them. These drivers included the AMD AU1XX0 MMC, the ARM Primecell MMCI PL180/1, the ATMEL AT91 MCI, the Motorola I.MX MMCI, the PXA MMCI, and the TI OMAP MMC Interface drivers. Pavel Pisa volunteered to maintain the Motorola I.MX MMCI driver and submitted a patch listing himself as the official maintainer.
Khasim Syed Mohammed said that Carlos Aguiar and Anderson Briglia would be interested in maintaining the TI OMAP MMC Interface driver for existing boards, and he (Khasim) would add support for new boards. Russell King volunteered to maintain the mmci.c file as well.
Chris Leech has posted some patches listing himself as the official maintainer of the DMA Generic Memcopy Subsystem and the Intel I/OAT DMA Driver. There doesn't seem to be any problem with this, except David S. Miller wants Chris to submit his patches to the netdev mailing list, since a lot of his work touches the TCP code.
Rajib Majumder recently asked whether Linux was able to scale up to 8 CPUs nowadays. Tony luck pointed out that systems with 512 and 1024 CPUs were already in production use, and a 4096-CPU system had been built as a prototype. Christoph Lameter predicted we'd be seeing a 16384-CPU system running Linux sometime in 2007. But Christoph also pointed out that hardware becomes a significant limiting factor with such high CPU counts, and a good filesystem (he recommended XFS) would also be essential.
Once a valiant entryway into the Linux world, UMSDOS has been gone since 2.6.11. Or, UMSDOS has been almost gone. Jesper Juhl has recently posted patches to remove a few remaining config options and file references. The only things now remaining of UMSDOS are the entries in the CREDITS file and the ioctl numbers UMSDOS used.
Originally, Jesper's patch removed the ioctls as well, but this raised some alarms with H. Peter Anvin, because ioctls should not be reused by other code, even if they go defunct.
Jesper's later version of the patch documented all of UMSDOS's removed ioctls so no one would mistakenly use the same numbers.