"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 but x86 had not had the need until now."

"Basically, what the gcc developers are saying is that gcc is free to load and store to any memory location, so long as it behaves as if the instructions were executed in sequence," Nick Piggin noted, describing a linked discussion on the GCC development mailing list. He explained his concerns, "for x86, obviously the example above shows it can be miscompiled, but it is probably relatively hard to make it happen for a non trivial sequence. For an ISA with lots of predicated instructions like ia64, it would seem to be much more likely. But of course we don't want even the possibility of failures. The gcc guys seem to be saying to mark everything volatile that could be touched in a critical section. This is insane for Linux." Linus Torvalds reflected:

"Are you surprised? The gcc developers seem to have had a total disregard for what people want or need, and every time some code generation issue comes up, there's a lot of people on the list that do language-lawyering, rather than admit that there might be a problem.

"It's happened before, it will happen again. I don't think it's true of all gcc developers (or even most, I hope), but it's common enough. For some reason, compiler developers seem to be far enough removed from 'real life' that they have a tendency to talk in terms of 'this is what the spec says' rather than 'this is a problem'."

"Despite my heart-felt feelings that we should support different people in trying out different things, one of the issues is also that I'm obviously not myself a security person. I can 'decree' all I want, but in the end, I really want the people *involved* to merge security stuff," Linus Torvalds explained during the ongoing discussions surrounding the Linux Security Modules code. He added, "there's the 'core LSM hooks' on one side, but there's also the 'what modules make any sense at all to merge?' on the other, and I really don't have the expertise to make any sensible judgments except for the pure 'process' judgment that we should not hardcode things to just one module!" Linus pointed out that Chris Wright is currently listed as the only LSM maintainer, but hopefully others would step up to help:

"Quite frankly, I do not want to take it over. I really really really hope that people that are interested in security can work this thing out, and my only requirement is that it doesn't end up being any kind of force-feeding of opinions and ideas, since clearly there is tons of room for disagreement in the area.."

"The Manageability Engine Interface (aka HECI) allows applications to communicate with the Intel(R) Manageability Engine (ME) firmware. It is meant to be used by user-space manageability applications to access ME features such as Intel(R) Active Management Technology, Intel(R) Quiet System Technology and ASF," Anas Nashif began, describing a new driver for accessing services found in most recent Intel desktop chipsets. Andrew Morton offered an initial review of the patch and asked for additional information, "why do we want to include this code in Linux? What value has it to our users, etc? Basically: tell us more stuff.". Anas added:

"The core hardware architecture of Intel Active Management Technology (Intel AMT) is resident in firmware. The micro-controller within the chipset's graphics and memory controller (MCH) hub houses the Management Engine (ME) firmware, which implements various services on behalf of management applications. Additionally, flash memory houses system BIOS, code used by the management engine, and a third-party data store (3PDS) that enables applications to store information as needed in non-volatile memory."

"Can we please finish up this merge a little more before we freeze 2.6.24? The way we currently have leftovers of arch/i386/ and arch/x86_64/ is quite a nightmare and not how the other architectures were merged," Christoph Hellwig asked, leading to an insightful reply by Ingo Molnar. Ingo began by noting, "to answer that question one should first be aware of the fundamental code quality problems that the unified x86 architecture has inherited from the split i386 and x86_64 architectures." He then utilized the checkpatch script to generate a table of "coding style errors per one thousand lines of source code". In his table, arch/i386/ rated 77.3 errors per thousand lines of source, with arch/x86_64/ rating 96.0. The new unified arch/x86/ rated a lower but still very high 74.1. He summarized, "it is plainly obvious that the x86_64 and i386 architectures were in a dreadful state of code quality before the unification. Their code quality was almost an order of magnitude worse than that of the core kernel (!) - and their code quality was significantly worse than that of a couple of other, comparable architectures." Ingo continued:

"So to answer your question: full unification is no easy task and it is not automatic at all. The x86_64 tree has diverged from the i386 tree in the past 5 years due to their illogical, forced separation and a resulting bitrot. The two architectures have grown different sets of cleanliness problems and different sets of functions with arbitrary differences that often cover the same functionality. It's all compounded by the fact that the 64-bit code is in worse shape than the 32-bit - so it's not like we could just pick the 64-bit code and use that as the unified code. The 32-bit code is also used about 8-10 times more frequently than the 64-bit code. So there is no easy 'just unify it' path."