|
The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching 10,000 messages in a 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. |
Over the past month, a few maintainership changes have been made. The list of maintainers of Intel Ethernet drivers has grown by one name - Alex Duyck is now responsible for the igbvf driver.
Andy Walls has also replaced Hans Verkuil as the official ivtv Video4Linux maintainer. Hans had done the job for more than four years, but Andy had begun to do more coding on it than him, so the maintainership change only formalizes what has been the case in practice. Along with this change, the developer mailing lists are now marked as moderated for all posts from non-subscribers.
Dan Williams is taking over maintainership of I/OAT from Maciej Sosnowski. Intel's I/O Acceleration Technology is used for speeding up network data flow.
Matt Turner is joining Richard Henderson and Ivan Kokshaysky as a new co-maintainer of the Alpha Linux port. The 2.6 code is now the only version maintained; Alpha Linux 2.4 is no longer listed as receiving even the odd bug fix.
Tomi Valkeinen is taking over from Imre Deak as the omapfb maintainer.
Also, Colin Leroy has said that he no longer has the hardware to continue maintaining the ADT746X fan driver, so he's posted a patch to remove the entire driver entry from the MAINTAINERS file.
Greg Kroah-Hartman posted a status report on the set of available stable kernel trees. Apparently 2.6.27-stable will be maintained for at least another half year, but fewer and fewer fixes are being back-ported to it. Eventually, it'll just quietly go out of date, although Greg did say that someone else had volunteered to maintain it after he lets it go. Also, Willy Tarreau confirmed that he was the poor sap - I mean, the earnest volunteer - who agreed to carry on with 2.6.27 when Greg is done. But Willy also confirmed that even under his maintainership, development on that tree will drop to a very slow crawl.
Greg also said that the 2.6.31-stable tree has seen its last fix. It's not a long-term tree; it's just been stable enough that 2.6.31 users can rely on it until they can upgrade to the next stable tree.
The 2.6.32-stable tree will be the next long-term tree, as 2.6.27 was. Greg expects to maintain it for another two or three years. The main reason for choosing this kernel has been that various Linux distributions chose it, so it just makes sense to keep something good and solid for them to upgrade to as needed. Greg added in very strong terms that he would only continue to maintain that tree as long as the distribution maintainers kept feeding him fixes.
Willy also praised Greg for letting folks know about the 2.6.32 tree, and he encouraged everyone to start feeding fixes and back-porting patches for that tree right away.
Len Brown from the Open Source Technology Center announced a Linux power management mini-summit for August 2010; he invited people to ask to attend, although he cautioned that they'd want to limit the group to around 20. He said that afterward, the minutes of the summit would be posted online as in previous years. http://lwn.net/Articles/345007/ http://lwn.net/Articles/292447 http://lwn.net/Articles/249019
Dmitry Golubovsky asked if User-Mode Linux was stable, and if development had ceased on it for that reason. Américo Wang replied that development was still going strong; Jeff Dike, the maintainer, said that he himself had not done much on UML in the past year, but that folks like Américo still contributed bug fixes.
Another feature struggling out of the "experimental" bin is middleware support for the CAPI stack. Jan Kiszka announced that in spite of any remaining bugs, the feature was very heavily in use and should no longer be considered experimental. But Alan Cox gave a mild rebuke, saying that although it was great that Jan had been fixing a big pile of problems in the code, there were still some significant flaws remaining. So, Jan said he'd start tackling those remaining issues, and he and Alan discussed the technical details of the best way to go about that.
H. Peter Anvin proposed ditching the CONFIG_X86_CPU_DEBUG build option. Originally, this had created entries in DebugFS for the CPU configuration on x86 machines, but because that information was already available to user-space in other ways, it had never been much more than a convenience. And, as Andrew Morton pointed out in the discussion, the feature had caused certain systems to lock up, and the problem hadn't been fixed after six months of being a known bug. Peter suggested deprecating it for a while, but Linus Torvalds said that clearly if six months had gone by without activity, the feature was dead and should just be removed, even in preference to fixing it. Ingo Molnár liked the simplicity of Linus's suggestion, so Peter submitted a patch to yank the whole thing out of there.
Simon Kågström felt that Linux didn't crash enough, so he posted patches to make it easier for users to cause system failures at will. OK ... no, what he actually did was post patches that would let developers provoke particular types of errors via a debugFS interface. With the use of such an interface, users could trigger a null pointer dereference, a stack corruption, a kernel panic, and various other things that would turn a healthy running system into a massive train wreck.
The feature is disabled by default, so users have to configure it explicitly to gain the special crashing power. It also turns out, as Andrew Morton remarked in the discussion, that people had created throw-away ad hoc versions of this type of feature many times over the years, so it would be good to just do it right one time and save folks "from having to rererereinvent that wheel."
Kay Sievers pointed out that devtmpfs, the kernel feature that creates a TmpFS filesystem under /dev at bootup, was in use by all major distributions, so the feature really shouldn't be marked as experimental. Kay posted a patch to enable the feature by default and to change the wording a bit in the kbuild description. Arjan van de Ven said that removing the experimental tag sounded fine but enabling the feature by default seemed over the top to him. Greg Kroah-Hartman pointed out that with distributions shipping with the feature enabled, it made the most sense for anyone compiling their own kernel from scratch to have the feature enabled as well; otherwise, their systems might not work.
Alan Cox pointed out that actually SUSE, Ubuntu, and various Fedora distributions, in fact nearly all distributions currently listed as stable and maintained, did not enable devtmpfs, whereas Kay said that the versions of Fedora, SUSE, and Ubuntu that were currently in development (i.e., soon, but not yet stabilized) all enabled devtmpfs. Kay argued that the upcoming swath of soon-to-be-released distributions would require devtmpfs, and Alan said that would be fine, but the situation should be clearly documented so that nobody would get burned using either the older non-devtmpfs systems or the newer devtmpfs-enabled systems.
But more folks were also opposed to enabling devtmpfs by default. As Pavel Machek pointed out, maintaining backward compatibility was important. It wouldn't do to have users doing incremental kernel updates not see the new feature enabled, while people compiling the kernel from scratch would see the new feature enabled by default. And, Arjan also pointed out that Linus Torvalds had said back in 2008 (caps his), "NO NEW FEATURES SHOULD _EVER_ DEFAULT TO `ON'!"