|
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. |
Kentaro Takeda has created an entry for the Tomoyo Security Module in the MAINTAINERSHIP file and listed himself and Tetsuo Handa as co-maintainers.
The I2C mailing list is following the general stampede of Linux mailing lists away from their own individual servers and onto vger.kernel.org. Greg Kroah-Hartman has posted a patch removing all references to the old mailing list at lm-sensors.org from the MAINTAINERS file and replacing them with references to linux-i2c@vger.kernel.org.
Thomas Sujith has created an entry for Intel's Menlow thermal drivers and listed himself as the official maintainer.
Bjorn Helgaas has added himself as a co-maintainer, along with the existing maintainer Adam Belay, of plug-and-play support. Actually, he added himself back in August, but with Andi Kleen pushing the code upstream and Len Brown taking it and incorporating it into the kernel, a multi-month gap developed.
Jonas Bonn has been thinking a lot about clocks. A given system can have various clocks, including the CPU clock, the bus clock, and clocks on various external devices. The tools available to deal with the various clocks, such as cpuidle and cpufreq, tend to provide overlapping features, Jonas says, while requiring special handling on a system-by-system basis. Jonas has proposed creating a single overarching API to allow the programmer to set various constraints, such as the target power usage on a given system, while handling the coordination of all clocks on the system behind the scenes so the developer won't have to think about it.
Various folks like Jon Smirl spoke in favor of this general idea but also pointed out that it was similar to other efforts already underway. As Mark Brown pointed out, Dmitry Baryshkov had been working on a generic version of the existing clk API, and Alan Jenkins mentioned an OMAP project coming out of the Ottawa Linux Power Management Summit in July. After examining these various alternatives, Jonas decided that the best way forward would be to enhance the API in the existing clk code. He said, "I have implemented this interface for the S3C2410, and it provides the functionality that I want, namely that clocks become first-class citizens and can be adjusted without specific knowledge about all the underlying devices that may or may not be using them at any given time."
Jon Smirl has coded up support in ConfigFS for infrared input devices. With the use of his code, pressing buttons on IR input devices will cause a lookup within the ConfigFS directory tree to identify the appropriate keycode to generate and, from there, the corresponding keystroke. Therefore, it is now possible to use infrared keyboards under Linux that will comfortably transmit user input through ConfigFS and into the system.
The eCryptFS filesystem continues to make plenty of interesting progress. Recently, Michael Halcrow, Tyler Hicks, and David Kleikamp implemented code to encrypt file names on the system. Their code relies on a passphrase to derive an encryption key that is then specified as input at mount time. An interesting detail is that the encryption process yields an encoded file name that might be slightly longer than the original; so, if the original file name is already close to the maximum length allowed by the system, eCryptFS will be unable to encrypt that name.
File name encryption is also optional. Each encrypted file name is stored with a prefix that identifies it as an encrypted file name, and not just the user's choice for the name of that file. To avoid confusion over which file names really need to be decrypted and which merely have the special prefix because the user included it as part of the legitimate name of the file, eCryptFS also stores the rest of the file name in a particular format. If eCryptFS sees the prefix that usually indicates an encrypted name but does not see the appropriate format for the rest of the encrypted file name, it assumes the file name was not actually encrypted, and that the user intended it to have the name it has.
Pierre Ossman has been running interference on flash MMC memory card code submissions, but recently he had a wave of self-doubt. He asked for feedback on how well he'd been handling his own feedback on other folks' code contributions, and he exhorted folks to take up some of the slack and give their own comments on MMC submissions. A big pile of people responded that they thought he'd been doing a great job giving his feedback - even in cases in which the person praising him was somewhat frustrated at not being able to get code past his rigorous inspections.
Stephen Rothwell recently clarified the requirements for being included in the linux-next tree. For starters, a tree would only be included in linux-next if its patches had been posted to the relevant mailing lists and been properly reviewed. The tree must also have been unit tested, and it must be the maintainer's intention to merge the tree into the official kernel during the next available merge window.
Stephen also explains what events might conspire to cause a tree to be dropped temporarily (i.e., until the problems are addressed) from linux-next. This includes any conflict with Linus Torvalds' tree that is not trivial to resolve. Any tree that won't successfully build also will be dropped. This goes along with the idea that the trees in linux-next should really be tip-top from the get-go, since they are angling to go right into Linus' tree. Another way to get a tree bumped is if it conflicts with other trees in linux-next in ways that are not trivial to resolve. The unstated assumption is that if your tree conflicts, you must have caused the conflict and should therefore be the one to resolve it. In practice, both conflicting tree maintainers can work together to resolve the conflict.
All of this represents a slight change in Stephen's policy. Until now, he had been willing to make patches on his own to allow the code to build successfully. But from now on he will not. Any tree that doesn't build, he said, will be dropped until it is fixed. On the other hand, Stephen said he is still willing to fix slight conflicts between trees and doesn't intend to be a stickler about insisting that even the most trivial conflicts result in a tree being dropped. During the merge window, he would hope to see virtually everything drop out of linux-next and be folded into the main-line kernel. Outside of the merge window, Stephen said he intended to keep the tree in a state that Andrew Morton would find convenient for creating his own -mm trees.
The code for IXP4XX CPUs has been inadvertently unmaintained for awhile. Russell King had been asking for a maintainer, and Imre Kaloz had volunteered, but as it happened, he'd been inundated by "real life" issues and hadn't been able to do anything about it. Finally when Miguel Ángel Álvarez asked point blank who the maintainer was, Imre piped up and said he hadn't been able to do it as actively as he had planned. Russell said this was a terrifying development and that the code would be completely stymied until a real maintainer could be found. But Imre said that life had eased up and he'd be able to review the pending patches again. So, crisis averted.