|
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. |
The effort to get bad, unmaintained, or unused code out of the kernel continues unabated. JFFS is slated for removal in 2.6.21, unless some secret cache of users is discovered. It's been unmaintained for years and been superseded by JFFS2 for years as well. Jeff Garzik made the proposal to get rid of it and submitted a patch; and Andrew Morton has no objection, so it looks like very nearly a done deal. Farewell JFFS!
Getting rid of OSS sound drivers has been on Adrian Bunk's to-do list for years, and he's gotten rid of quite a few of them, as more and more ALSA drivers start working just as well for the same hardware. DMASOUND_PMAC and SOUND_ES1371 are the latest two heading for the chopping block. Thomas Sailer and Kyle Moffett have both given their personal confirmation that these drivers may be safely removed, and no voices have been heard in objection.
Adrian has also tried removing the VIDEO_ZR36120 driver, but in this case, he's encountered some resistance. It turns out Joe Feise uses the driver and has even patched it to work on his home system; though when he submitted his patch to the official maintainer, Pauline Middelink, he got no reply and the patch was not adopted into the kernel.
Peter Schlaf also uses the driver and had been using a forked version of Pauline's code to support it. On the mailing list, Schlaf offered to take over maintainership of the driver, and Pauline said this would be fine. And Mauro Carvalho Chehab offered to accept any patches coming in for the driver, since he maintains the V4L subsystem as a whole. So it looks as though this particular driver has been saved from death at the very last moment.
The VIDEO_PLANB driver also found a new maintainer. Adrian posted a patch to remove it, but Benjamin Herrenschmidt volunteered to take a stab at fixing it up. And Michel Lanners, the original author of the code, expressed great interest in helping out with explanations of the hardware and existing code, al-though he had no time to actually maintain the driver.
The SCSI_AMIGA7XX driver is up in the air now. Adrian posted a patch to remove it, but Geert Uytterhoeven offered his assessment, saying, "There's a fix available to convert this driver to the new 53c700 core. But it needs the new DMA framework, which still causes a few regressions on m68k that are being worked on." Whether this will be enough to keep the driver alive is an open question.
Other drivers are more cut and dry. Adrian submitted patches to remove the BINFMT_IRIX driver, the FB_S3TRIO driver, the SUN_AURORA driver, and the OAKNET driver. No one stepped up to claim them. In the case of the S3Trio, Geert Uytterhoeven pointed out that a new generic S3Trio driver was in the works, so there was really no need to cling to FB_S3TRIO.
With all the old code coming out of the kernel, there are still a lot of features that are being added and old features being fixed. Andries Brouwer recently had to read a Minix version 3 filesystem, only to discover that 2.6.19 didn't support it and neither did the latest 2.6.20 release candidate.
A quick search revealed that Daniel Aragones had already written a patch to support the filesystem, and after cleaning it up quite a bit, Andries submitted it to the kernel list for inclusion. Daniel approved of Andries's changes, and Andrew Morton said the patch looked harmless enough to accept right away.
Jiri Kosina has resurrected the ipwireless_cs 3G PCMCIA network driver, originally developed by Symmetric Systems, and forward-ported it to the current 2.6 kernel. The original authors are also participating in debugging and enhancing the code. There is a lot to be done! The code itself violates CodingStyle rules and fails to use various in-kernel resources; and its support of the hardware itself is buggy. But Jiri and the rest have felt a pulse on this one! A working driver cannot be too far in the future.
Sascha Sommer has implemented an experimental driver for the Ricoh SD Card reader, as found in notebooks such as the Samsung P35 and the DELL X300. Samuel Thibault is super excited to see this work going on, and Pierre Ossman offered his encouragement as well. The driver currently offers read-only support, is slow, and has a variety of other problems; but Samuel was able to use it on his X300.
David Brownell has written a driver framework for the real-time clock built into PCs and some other platforms. This is not an entirely new thing, a real-time clock driver exists already. But David's work has a more extensible feature set, and a standard user interface via SysFS. Drawbacks are that it's only been tested on x86 with ACPI and no HPET and therefore can look forward to some "growing pains," as David puts it.
Philip Langdale has coded up some support for the upcoming SDHC (Secure Digital High Capacity) flash cards. John Gilmore donated the hardware, and as the SD Card Association has published useful specifications, he was able do it! The code has not been widely tested yet, but Philip has not lost any data in his recent tests.
David Lopez recently submitted a driver to support LabJack U3 and UE9 USB data acquisition devices. These devices provide a general purpose connection between a computer and laboratory instruments.
Nicolas Ferre has modified the ads7846 driver code to support the ads7843 touchscreen controller.
It seems there is also some work being done on that driver elsewhere, and folks seem to be scrambling around trying to sort out which patches are where, and who to ask. But there don't seem to be any insurmountable problems.
Matti Aarnio is trying Postgrey filtering for the linux kernel mailing list. This involves delaying each email by up to five minutes, because legitimate mail servers will automatically try to resend the email, while most spammers don't bother.
Matti's initial measurements show a 90% drop in spam coming into the list as a result of this change. However, he predicts that within 200 days, most spammers will wise up and start retrying their deliveries like legitimate mail servers. So his change will only provide a brief respite from spam, rather than a long-term improvement.
Richard Knutsson suggested changing the format of the MAINTAINERS file slightly to include the actual configuration variable for each project listed there. This way, anyone having a problem with a driver could run a script that would query the MAINTAINERS file for the correct owner and project status. Several kernel folks support this idea, and Matthias Schniedermeyer also suggested splitting the MAINTAINERS file into smaller files, as was done with the monolithic kernel configuration file before KConfig came along. Among folks like Andrew Morton, however, these ideas have not yet taken root. As Andrew puts it, "I find that the most practical way to find out who really maintains a driver is to run git-whatchanged on it and see who has been doing stuff to it."
Meanwhile Leonard Norrgard has also been interested in automatically parsing the MAINTAINERS file; and to that end, he has submitted a patch to convert occurrences of "Orphaned" status lines into the more canonical "Orphan" state. It remains to be seen, whether scripts that read the MAINTAINERS file will soon be replaced by git-whatchanged.
Meanwhile, there have been some actual maintainership changes. Aside from the odd updated email address or website URL in various projects, Martin Waitz has abdicated maintainership of the kernel-doc DocBook effort, leaving the project entirely in the hands of Randy Dunlap, his comaintainer. Martin said he didn't have the time to put into this effort anymore, so it made no sense to keep himself listed as an official maintainer.