|
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. |
Nigel Cunningham has submitted Suspend2 to Andrew Morton for inclusion in the -mm tree, presumably in preparation for it going into the main kernel. Pavel Machek has stood opposed inclusion for a long time, doing work on his own competing uswsusp project, from which Nigel originally forked Suspend2.
A lot of users want to see Suspend2 go into the kernel, and some feel that Pavel is unfairly blocking efforts to include it. As the software suspend maintainer, Pavel has a lot of veto power over any code going into that area. And no one could blame him for feeling bitter that Nigel forked his project and then did a (as some say) better job at it than Pavel.
Still, it does seem as though Nigel's work is gaining quite a large following, and its absense from at least the -mm tree is becoming conspicuous, given how well it works and how much people love it.
The behavior of the magic SysRq key may be changing to support more users, though not everyone seems to be happy about it. Traditionally, when configured into a kernel build, pressing and holding the alt-sysrq key combination causes the kernel to respond to additional key presses as kernel commands regardless of anything else it may be doing, unless the system is actually locked up solid. It's an extremely useful tool for kernel developers, and it is often helpful for regular users as well.
The problem is that some keyboards don't like it, because their controllers can't recognize three simultaneous key-presses. Users like Alan Stern were getting error messages from that key combination, instead of getting the help they needed from the kernel.
Andrew Morton, Pavel Machek, and others have `fixed' the problem by changing the behavior of the magic SysRq key, so that it's possible to only hold down the alt key, then press and release sysrq, then press and release a third command key of choice.
This makes it at least possible to use magic sysrq on finicky keyboards, but folks like Roman Zippel are unhappy with the change, saying that it breaks the well documented behavior the magic sysrq had in the past and will be confusing to users who were not experiencing any problem. Roman argues that it should be possible to support both the old and the new behavior.
In response to this, Paulo Marques actually tried to support both behaviors, and with some help from Dmitry Torokhov, he did seem to be making progress on coming up with an appropriate solution.
The only definitive decision made during the thread, however, was that one way or another, the broken keyboards would be fixed. Whether this will ultimately include supporting old behaviors will probably be determined by how successful Paulo and Dmitry are at wrangling the code into shape.
One of the most interesting things about the ReiserFS debate is that each side believes the other is politically motivated. Hans Reiser believes the kernel developers don't like him and are intentionally being obnoxious, refusing to include Reiser4 when they already (for example) have plans to include the as-yet unwritten ext4. He says the kernel folks have a tendency to alienate good talent, sending powerful contributors to work on other operating systems instead of welcoming them into the fold.
Kernel developers, for their part, say that the Reiser4 code has technical problems and plays badly with the rest of the kernel. They say that Reiser has responded to their technical arguments with "marketingspeak," personal attacks, and accusations that the kernel developers are only behaving politically. Many kernel developers who would be in a position to help Reiser4 get accepted, for example, Theodore Tso, have decided to recuse themselves from ever reviewing code associated with Hans, because of the grief he has given them in the past.
The absense of reviewers for the Reiser4 code makes it even harder to get Reiser4 considered for inclusion in with the kernel.
It may be time for Hans to delegate the task of interacting with kernel developers to someone else in his company. The kernel folks have suggested this possibility of delegating some of the responsibilities one way or another, saying that his technical people are a lot easier to work with, and they stick to the technical points without resorting to personal attacks. Maybe, as the good leader he claims to be, Hans should let the people who work well together work together, and just take himself out of the process entirely.
Maybe this shift of responsibilities will help get the kernel people started with giving real technical reviews and feedback to the Reiser development team again.
The /proc directory continues to trouble people due to its awful messiness. Jon Smirl recently suggested removing /proc/tty as a step in the right direction, because it hard-coded device names, and this was not compatible with udev's ability to rename devices.
Unfortunately a fair bit of software relies on /proc/tty, including the ps command, which, as Mike Galbraith has pointed out, uses /proc/tty/drivers. In response to this, Jon took a look at the ps command source, and started fixing it, but Alan Cox also pointed out that a lot of package installers and system management tools also used /proc/tty, so it wouldn't be just a simple matter of a few fixes to clear the path.
At one point Greg Kroah-Hartman weighed in, saying he did, in fact, want to get rid of /proc/tty eventually, but he didn't think it could be done now, and he especially didn't want to break any user-space tools if he could avoid it.
It looks like the Areca RAID driver will be merging into the main kernel tree, after some struggle. Robert Mueller pointed out that the patch had been edging toward inclusion for over six months, and had Andrew Morton's support, but that there were still some remaining problems with the code. Robert asked if these problems were still show-stoppers, or if the driver could finally be merged. As it turned out, Andrew was more than happy to do this (his actual quote was, "One and a half years. Would the world end if we just merged the dang thing?").
Some folks felt the maintainer, Erich Chen, had not been active enough in fixing the remaining issues; but this turned out not to be the case, and Erich also took the opportunity to submit additional fixes. His patches were not perfect, and Andrew had a number of technical suggestions; but it does look as though the Areca driver will be merged in the very near future.
Kernel memory management recently went through some maintainer shenanigans. Andrew Morton had been officially named the maintainer years ago, but an entry was never logged in the MAINTAINERS file. Steven Rostedt decided to add the entry, and, not knowing better, he selected Christoph Lameter as a likely candidate. This turned out to be not the way maintainers are selected in Linux, as was gently explained to Steven.
As Peter Zijlstra pointed out, "the maintainership of the memory management code is as follows: there is explicitly no maintainer listed. This code is so sensitive and has interactions with so many other subsystems that it would not be doable to look at it from all possible angles by only one person. As it stands, it's more a group of people headed by Linus, Andrew, and Hugh."
Ultimately it was decided to list memory management in the MAINTAINERS file after all, with mailing lists and web sites but no specific maintainer.