|
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. |
Eric Leblond posted a short patch to support the Sierra Wireless AC850 3G Network Adapter. The patch was simple to add because the code is the same as the AC710/750; it just uses different firmware.
Stephen Hemminger, continuing work originally done by Jochen Eisenger, posted code to support the application buttons on some Fujitsu Lifebook laptops. Apparently only some models are supported so far, with more on the way.
Yoichi Yuasa posted some code to support the LEDs on the front of the Cobalt Raq and listed himself as the maintainer.
Tejun Heo posted a patch to make sure that when SysFS files were renamed, all symlinks pointing to those files would be renamed automatically as well. For backward-compatibility purposes, he included an exception for links created with the kobject-based sysfs_create_link().
Alan Cox has abandoned maintainership of IDE-CD, mainly because he has no interest in fixing old IDE bugs anymore. Alan posted a call for someone to take his place, saying that if no one stepped up, he'd ask Andrew Morton to mark the code as unmaintained.
After 10 days, no one had answered his call so he posted a patch to do this (though Stephan Richter pointed out that it should really be marked "Orphan" instead of "Unmaintained"). And Jens Axboe felt the solution would be to fold the IDE-CD code directly into the main IDE subsystem and let it be maintained as part of that. For now, it seems that the code is going to sit idle.
On a similar note, Bartlomiej Zolnierkiewicz posted a patch to mark IDE-SCSI as orphaned.
Randy Dunlap changed the "TI OMAP MMC INTERFACE DRIVER" entry in the MAINTAINERS file to reflect the fact that the mailing list for that project could only be posted to by subscribers.
Marc Espie expressed his concern over the fact that some kernel developers seemed to be taking code that had been dual-licensed under the GPL and ISC licenses and dropping the ISC license from their own releases. Dropping the ISC license meant that the code could only be reused in GPLed projects. Marc felt it was unfair for the Linux folks to do this. He asked, "Do you intend to keep grabbing BSD code and putting it exclusively under the GPL ?"
Michael Tharp had a different perspective and said, "That's the bittersweet side of BSD licensing - others have every right to take your code and use it for their own projects without having to give their changes back to you." And Jeff Garzik also pointed out that the dual-licensed files explicitly allowed the user to pick just one license from the two. But as Bernd Petrovisch put it, "I could take BSD- (or ISC-) licensed code (legally), patch it, sell it (or not), and (legally) not give back anything, putting the whole code effectively under proprietary license."
In my opinion, this seems to be the fundamental dilemma of all BSD-like licenses. It's true that they are "freer" than the GPL because they don't restrict the user from relicensing the code, even under a proprietary license. By the same token, by choosing the BSD-like license, developers lose the right to be taken seriously if they complain that other people relicense their code. If they don't want to see relicensing, they should use a license that explicitly forbids relicensing. To the people who ask, "Aside from legality, is it ethical to relicense BSD-licensed code?," my opinion is that of course it's ethical, just like forking a GPLed project is ethical - it's allowed by the license.
The social niceties of when and how to fork a GPLed project have grown out of the experience of what naturally produces the best projects, not by some abstract notion of what's right. If someone forks a GPLed project in a way that doesn't inspire others to work on it, someone else will fork in a better way. BSD proponents introduce the idea of ethics when they complain about relicensing because of the huge hole they've left open in their license that allows their code to be used in ways they don't like.
Peter Stahlir suggested that it might be nice to have git at the back of a filesystem. Peter's take was that this would save a lot of space via pack-file compression; he wasn't so interested in the version-control aspects of a git-based filesystem. Muhammad Tayyab thought this would give too much of a performance hit, and Adrian Bunk pointed out that git relied on zlib for compression, which he said was "neither unusual nor the best compression method available." In general, there was not much support for a git-based filesystem. But anything can happen.
On Jeff Garzik's request, Randy Dunlap wrote up some documentation about the various email clients that might be used to send patches to the linux-kernel mailing list and how best to send patches - regardless of the client. The overall preference is that folks send patches inline as part of the message body so that portions of the patch can be quoted during the review discussion. It's also essential that the email client not modify the patch in any way, for example, by converting spaces or tabs. Emails sent in HTML are strongly frowned upon.
The document is still fairly new, but eventually it will contain configuration options that will make patch submissions most likely to work well with various clients. A bunch of folks replied to Randy's initial post with details about the different clients, so we can expect this document to mature rapidly.
One problem that plagues software developers is the presence of unnecessary compiler warnings for code that is either outdated or needlessly strange. Satyam Sharma spent a weekend slogging through a lot of old, messy code throughout the kernel to eliminate as many compile-time warnings as possible.
The result of Satyam's work was a much cleaner build. Jesper Juhl was pleased by this and said, "It's just so much easier to spot the real problems when the build doesn't spew a ton of pointless warnings." So, for at least a brief moment, it will be a lot easier to spot significant problems during a routine compile.
Perhaps with the continuing efforts of developers such as Satyam, Jesper, and anyone else who's interested the task of uncovering and eliminating messy kernel code, clean builds could start to be more common among official kernel releases.
Here's an interesting problem - it is possible to have multiple identical filenames in a directory in /proc. Clearly this should never happen, but when Zhang Rui posted a patch to return an error code when drivers tried to create such duplicates, Oliver Neukum pointed out that the real problem was with the drivers themselves. Simply stopping duplicate file creation, Zhang argued, only obscured the true bugs lurking in the driver code. And as Andrew Morton also pointed out, Zhang's change would change the system's behavior so as to break many otherwise working systems. A better solution, Andrew said, was to detect the duplication and log a warning. Zhang quickly posted a patch to do this and Andrew accepted it.
| INFO |
|
[1] Kernelnewbies Japan: http://lists.kernelnewbies.org/mailman/listinfo/jp-kernelnewbies
|