|
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. |
Adrian Bunk has been plugging away at OSS Driver deprecation and removal for quite a long time now; bit by bit, he hunts down those drivers, works to improve the ALSA equivalents, gathers information, and removes each OSS driver that will not cause too much backlash.
Recently he put out another call for help. The three cases he wants to identify are fully working ALSA drivers for the same hardware as an OSS driver, problematic or broken ALSA drivers for the same hardware as an OSS driver, and OSS drivers with no ALSA equivalent.
For all drivers in the first category, he plans to set an aggressive schedule for OSS driver removal. For drivers in category 2, he will set a time frame within which ALSA bugs may be reported. All OSS drivers with no working ALSA equivalents are retained in the kernel.
Each of his calls for assistance has resulted in significant progress. About 50 drivers remain to be either removed, fixed, or ported to ALSA by someone.
Greg Kroah-Hartman has discovered a number of files that have been in the kernel for years - at least since before BitKeeper's use - and that have prominent notices of apparent copyright restrictions, saying things like, "this is unpublished proprietary source code of Motorola."
As it turns out, the code is properly licensed under the GPL, via a README in the same directory. But Greg and others feel that the language in the source files themselves could be confusing to anyone who didn't know better.
The true owner of the code turns out to be Freescale, a spin-off from Motorolla as of July 2004. Matt Waddel from Freescale has offered to adjust the copyright notice to be less confusing. But as Alan Cox has pointed out, there was no actual problem with the copyright notice; Matt's adjustment will just be for the convenience of developers; it is not intended to alter the legal meaning of the notices.
The attitude of many kernel developers toward the inclusion of Reiser 4 into the kernel seems to be one of careful indifference. According to some of them, the Reiser developers just have to "submit it in a mergeable state"; which suggests that communication between the Reiser developers and the kernel developers has broken down: the kernel folks feel they have explained what the Reiser folks must do, and now all that remains is for the Reiser folks to do it, which they have not done yet.
Usually when a regular user posts to ask about the status of a given kernel feature, someone with knowledge gives their estimate of how that feature stands. With ReiserFS, not only are no Reiser people coming forward with estimates, but no kernel people are willing to make anything more than vague speculations. Requests for further information are referred back to the mailing list archives, indicating that progress is at a stand-still, or at least that the kernel developers think it is.
It seems that, at least for the moment, a profound silence has fallen between the two groups. If kernel development stays true to form, eventually the Reiser people will submit more patches, and these patches will be critiqued by anyone willing to critique them, or else ignored if the issues raised previously raised have not been addressed.
Randy Dunlap recently posted a patch to move SATA configuration out of the SCSI area and into its own section. The rationale for moving SATA configuration out of the SCSI area into its own section is that SCSI is just a configuration detail that users don't need to know about in order to use SATA.
Although this idea may not be completely obvious, the reaction of kernel developers has been generally positive, with various folks offering minor suggestions to the patch.
But Randy himself has also put the brakes on future development of this proposed SATA configuration patch, saying that he was primarily interested in hearing what folks had to say; not in actually getting his patch accepted into the kernel.
Still, it seems that the idea itself is quite sound, and with the support of other kernel developers, a patch like this may inevitably work its way into the Linux kernel.
Adrian Bunk has made an attempt to remove the Raw Driver from the 2.6 kernel tree. This driver has been deprecated and marked for removal since 2.6.3, but it may be more difficult to get rid of than it might have seemed at first.
The Raw Driver allows raw input and output to be performed on block devices. Passing O_DIRECT to the open() system call performs a similar function, and is preferred, so the decision was made to deprecate and remove the driver in stages over time. However, a lot of third party software vendors have not yet finished converting their code to use O_DIRECT, and until they do, there will be continued resistance to taking out the driver.
As Alan Cox puts it, "obsoleting stuff which is distribution internal configuration type stuff is one thing but core syscall related stuff has to undergo a much much longer cycle."
Regardless of any reasons to keep the driver, the confusion over this issue is also an inconvenience to Adrian, who puts in considerable work toward sweeping out the kernel on a regular basis; and who now has found that some of this work has been wasted.
These things do come up. It may be that the Raw Driver can never be taken out. All too often, a decision about this or that kernel feature is made too soon, and the developers realize too late that much of user-land now depends upon it.
In worse cases, the attempt is made to rescind a bad decision, that attempt fails, and then both states must be supported for the long term. But in the lucky cases, marking something as "deprecated" in the kernel has been enough to motivate much of user-land to convert their code to a better system. Perhaps the conversion to O_DIRECT will be successful, and Adrian will yet remove the driver.
Michael Hanselmann has posted a patch to remove an old ATI Radeon framebuffer driver that had been replaced by a newer one. The removed driver had been marked as "Old" and had apparently received no significant updates since 2002.
Reaction among big-time kernel developers has been completely positive, although it's true that the newer driver also has problems. As David Miller has pointed out, the screen-blanking routine of the current driver can confuse the X Windowing system, making it more difficult to unblank the screen.
Michael Buesch has been attempting to rewrite the Wireless Extension (WE) API, a generic set of calls to interface with wireless LANs. The existing Wireless Extension API was written by Jean Tourrilhes under the auspices of Hewlett Packard. Michael's version relies on netlink sockets, a clean mechanism to communicate between the kernel and userspace. Although it is not yet ready for raw alpha testing, hopefully Michael's code will provide a simpler, cleaner interface between kernel space and any surrounding wireless network.