"The following patches add a new testing facility for suspend and hibernation," noted Rafael J. Wysocki. He continued, "the first patch adds the possibility to test the suspend (STD) core code without actually suspending, which is useful for tracking problems with drivers etc. The second one modifies the hibernation core so that it can use the same facility (it's a bit more powerful than the existing hibernation test modes, since they really can't test the ACPI global methods)."

The testing facility introduces a new /sys/power/pm_test_level attribute, accepting a number from 1 to 5, with each value simulating a different level of the suspend or hibernation code. Rafael explained: "5 - test the freezing of processes; 4 - test the freezing of processes and suspending of devices; 3 - test the freezing of processes, suspending of devices and platform global control methods; 2 - test the freezing of processes, suspending of devices, platform global control methods and the disabling of nonboot CPUs; 1 - test the freezing of processes, suspending of devices, platform global control methods, the disabling of nonboot CPUs and suspending of platform/system devices". He added, "if a suspend is started by normal means, the suspend core will perform its normal operations up to the point indicated by the test level. Next, it will wait for 5 seconds and carry out the resume operations needed to transition the system back to the fully functional state." Rafael noted that setting pm_test_level to 0 disables the testing facility.

"We are pleased to announce the official release of OpenBSD 4.2. This is our 22nd release on CD-ROM (and 23rd via FTP). We remain proud of OpenBSD's record of more than ten years with only two remote holes in the default install," Theo de Raadt announced. In addition to a lengthy list of new features and improvements, the release announcement includes a dedication:

"We dedicate this release to the memory of long-time developer Jun-ichiro 'itojun' Itoh Hagino, who focused his life on IPv6 deployment for everyone. Without his BSD and IETF participation, IPv6 would not be where it is today. Only now people are becoming aware of his numerous contributions because he took credit for much less than he accomplished. The developers in our project will all miss him."

"With great sadness, I regret to inform you that Itojun will not be presenting his great knowledge of IPv6 at PacSec. I have been informed by several sources that he passed away yesterday," Dragos Ruiu announced the unhappy news on the OpenBSD -misc mailing list. He noted, "funeral services will be held on Nov 7th at Rinkai-Saijo in Tokyo. There aren't many details of his passing, so please let his family and relatives mourn in peace for now." Dragos offered the following words about Itojun:

"I knew Itojun as one of the smartest and kindest persons I have ever met. He helped everyone around him. He graciously hosted and assisted many foreigners new to Japan at the PacSec conferences, and was a good friend to all. He would go to extraordinary lengths to help anyone around him. We will all miss him - and his work on IPv6 will continue to help us for a long time.."

"If you knew or respected him, he would have wanted any energy you put towards grief to be spent on speeding the adoption and the robustness of the version 6 internet to which he devoted so much of his extraordinary life to."

"A 'General Purpose Input/Output' (GPIO) is a flexible software-controlled digital signal. They are provided from many kinds of chip, and are familiar to Linux developers working with embedded and custom hardware, begins Documentation/gpio.txt. In a recent four patch series, David Brownell noted, "when we hashed out the Documentation/gpio.txt GPIO programming interfaces last year, there were a few features in the 'we want this eventually, but can live without it for now' category. Following this post are patches adding some of those features." He went on to describe the two new features introduced in his patches:

"1) Implementation framework in lib/gpiolib.c ... the interface provided to GPIO _users_ is unchanged, but providers can now hook up through a 'gpio_chip' that lets multiple types of GPIO provider coexist. Examples: SOC-native GPIOs, ones provided by an FPGA, I2C or SPI GPIO expanders, etc."

"2) I2C driver for common pcf8574/8575 GPIO expanders ... these are pretty common on embedded hardware, and it's routine for external trees to have ugly board-specific hacks exposing those GPIOs to drivers. Unlike such hacks, I think support using standard GPIO calls should be mergable upstream."

Jeff Garzik posted a two patch series introducing an asynchronous event notification infrastructure, "enabling SATA Asynchronous Notification ('AN') for CD/DVD devices that support it." He summarized:

"For devices that support SATA AN (only very recent ones do), this means that HAL and other userspace utilities no longer need to repeatedly poll the CD/DVD device to determine if the user has changed the media."

The first patch is for the SCSI driver and is based on work originally done by Kristen Carlson Accardi, along with "copious input from James Bottomley". The second patch updates libata to utilize the new SCSI event infrastructure.

Paul Mackerras merged an updated version of gitk into his master branch. Gitk is a git repository browser. New features include improve searching, "thus you can now search for commits that modify certain files or directories, or commits that add/remove a given string, as well as searching for commits by commit message, author, committer or headline." Paul also noted two performance improvements, "gitk now uses a new graph layout algorithm, which means it doesn't have to generate the whole layout from top to bottom at startup time, making startup faster," and, "gitk caches the topology information used for the previous/next tag and branch information, making startup faster."

Linus Torvalds noted some display annoyances, but responded favorably to the performance improvements, "*huge* improvements. It is now really nice to start up gitk even on the full kernel history." He made some suggestions for additional improvements, then added, "but this has both the layout performance improvements and the fixes to only show selected files in the diff view by default, so I hope this gets merged into standard git soon.."

"Quite frankly, at least for me personally, what I would rather have [...] is a less rigid maintainership structure," Linus Torvalds proposed. He went on to explain, "let's face it, we are *all* likely to be overworked at different times, and even when not overworked, it's just the fact that people need to take a breather etc. And there is seldom - if ever - a very strong argument for having one person per subsystem." He noted that git is an excellent tool for spreading out maintenance, then added, "but even without something like that, I think it's much better to try to find people you can trust, rather than strict maintainership boundaries." Linus continued:

"I've personally always been against _strict_ maintainer lines, so I've always taken stuff 'past' the maintainer anyway (and sometimes maintainers have complained, because they feel like they 'own' their subsystem, and I either tell them to stuff it, or say 'my bad', depending on whether they had a valid _technical_ complaint or not)."

"This patch corrects what I hope are invalid assumptions about the DMA engine layer: Not only Intel(R) hardware can do DMA, and DMA can be used for other things than memcpy and RAID offloading," Haavard Skinnemoen noted, submitted a small patch against the DMADEVICES Kconfig option. He added, "Don't get me wrong; I think Intel deserves lots of respect for creating this framework. But this is also why I got a bit disappointed when I discovered that it seems to be less generic than I initially hoped." Haavard continued:

"DMA controllers, which may support plain memcpy acceleration in addition to more traditional 'slave DMA', are very common in SoC devices, and I think Linux needs a common framework for it. The existing DMA Engine framework seems to come pretty close already, but I think it needs more input from the embedded crowd before it can be completely usable on a large number of embedded systems."

"I'd like to ask you to put a file in Documentation/ somewhere that describes what AppArmor's intended security protection is (it's different from SELinux for sure for example); by having such a document for each LSM user, end users and distros can make a more informed decision which module suits their requirements..." Arjan van de Ven suggested in an attempt to help focus future Linux Security Module discussions on technical issues. He explained, "it also makes it possible to look at the implementation to see if it has gaps to the intent, without getting into a pissing contest about which security model is better; but unless the security goals are explicitly described that's a trap that will keep coming back... so please spend some time on getting a good description going here.." Arjan continued:

"My main concern for now is a description of what it tries to protect against/in what cases you would expect to use it. THe reason for asking this explicitly is simple: Until now the LSM discussions always ended up in a nasty mixed up mess around disagreeing on the theoretical model of what to protect against and the actual implementation of the threat protection. The only way I can think of to get out of this mess is to have the submitter of the security model give a description of what his protection model is (and unless it's silly, not argue about that), and then only focus on how the code manages to achieve this model, to make sure there's no big gaps in it, within its own goals/reference."

Andrew Morton responded favorably to Evgeniy Polyakov's most recent release of his distributed storage subsystem, "I went back and re-read last month's discussion and I'm not seeing any reason why we shouldn't start thinking about merging this." He then asked, "how close is it to that stage? A peek at your development blog indicates that things are still changing at a moderate rate?" Evgeniy replied:

"I completed storage layer development itself, the only remaining todo item is to implement [a] new redundancy algorithm, but I did not see major demand on that, so it will stay for now with low priority. I will use DST as a transport layer for [a] distributed filesystem, and probably that will require additional features, I have no clean design so far, but right now I have nothing in the pipe to commit to DST."

A recent report on the lkml suggested improved IO/writeback performance in the recently released 2.6.24-rc1 kernel compared to the earlier 2.6.19.2 and 2.6.22.6 kernels. Credit was given to some patches by Peter Zijlstra. Ingo Molnar replied, "wow, really nice results! Peter does know how to make stuff fast :) Now lets pick up some of Peter's other, previously discarded patches as well :-)" He pointed to several patches "as a starter", then quipped, "I think the MM should get out of deep-feature-freeze mode - there's tons of room to improve :-/"

Andrew Morton replied, "kidding. We merged about 265 MM patches in 2.6.24-rc1: 482 files changed, 8071 insertions(+), 5142 deletions(-)". He added, "a lot of that was new functionality. That's easier to add than things which change long-standing functionality." Of the patches Ingo pointed to, Peter noted he was currently working on polishing the swap-over-NFS patch, "will post that one again, soonish.... Esp. after Linus professed liking to have swap over NFS." Rik van Riel also replied regarding rewriting the page replacement code, "at the moment I only have the basic 'plumbing' of the split VM working and am fixing some bugs in that. Expect a patch series with that soon, so you guys can review that code and tell me where to beat it into shape some more :)"

"This argument seems to start from the assumption that any externally maintained kernel code *can* get into the kernel, which doesn't stand up to reality. Once you admit that there is code which, for very good reasons, won't ever be accepted into the mainline kernel tree, what you are saying amounts to: 'Code that isn't fit to be included in the mainline kernel isn't fit to exist at all'," Tilman Schmidt argued during the ongoing debate about whether or not LSM should support modules.

Greg KH responded, "what kind of code is not accepted into the mainline kernel tree for good reasons? What are these reasons? What specific code are you talking about?" He pointed to a wiki page on the Linux Driver Project website and explained, "I'm trying to compile a list of all known external modules and drivers and work to get them included in the main kernel tree to help prevent these kinds of things."

"The __deprecated marker is quite useful in highlighting the remnants of old APIs that want removing. However, it is quite normal for one or more years to pass, before the (usually ancient, bitrotten) code in question is either updated or deleted," explained Jeff Garzik, posting a small patch to make it possible to silence "warning: 'foo' is deprecated" type messages.

Andrew Morton wasn't impressed, suggesting, "Sigh. Can't we just fix the dud code? Or mark it BROKEN and see what happens?" Linus Torvalds added, "I think removing __deprecated is the better option. Quite frankly, some people add '__deprecated' *way* too eagerly." Jeff agreed that __deprecated is over used, "__deprecated has spread to just about every API that people don't consider fresh and up-to-date." He then added ,"like I noted in the patch description, rewriting grotty ISA/MCA/etc. probe code is a thankless, boring task that few are crazy enough to attempt :) As you can see from the patch flood recently I /have/ been working through the dud code, but it will still take years. The changes required for each are on average ~200 LOC changed, if not more."

"This series kill the old i386 and x86_64 directories. The relevant files are moved and adapted and Kconfig.debug was consolidated (thanks to Randy)," Sam Ravnborg said, describing a set of 6 patches to finish the migration of physical files into the new x86 architecture directory. He described it as "a nice patch series that deletes more lines than it adds," going on to explain:

"I had to modify both the top-level Makefile and the kconfig Makefile to accomplish this. It was done in such a way that it is trivial for other archs to use the same mechanism should they have the need.

"To solve the defconfig issue (i386 and x86_64 cannot share one) the arch/x86/configs/ directory were introduced. This has been used by other archs for some time now