Prefacing a series of 196 patches, Greg KH noted, "due to the low level nature of these patches, and because they touch so many different parts of the kernel, a number of the subsystem maintainers have asked me to get them in first to make merging other trees easier." Linus Torvalds agreed and quickly merged the patches into his tree. Greg summarized the many changes:

"They can be broken down into these major areas: Documentation updates (language translations and fixes, as well as kobject and kset documentation updates.); major kset/kobject/ktype rework and fixes; struct bus_type has been reworked to now handle the lifetime rules properly, as the kobject is properly dynamic; struct driver has also been reworked, and now the lifetime issues are resolved; the block subsystem has been converted to use struct device now, and not 'raw' kobjects; nozomi driver is added; lots of class_device conversions to use struct device instead."

"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."

"I'm trying to keep some external drivers up to date with the kernel, and the first two weeks after the release is the worst time for me. There is no way to distinguish the current git kernel from the latest release. It's only after rc1 is released that I can use the preprocessor to check LINUX_VERSION_CODE," explained Pavel Roskin, describing the ongoing effort to keep the out of tree MadWifi driver in sync with the latest released kernel. Rik Van Riel suggested:

"Consider this an incentive to submit your code for inclusion in the upstream kernel. Having all the common drivers integrated in the mainline kernel makes it much easier for users to use all their hardware, external drivers are not just a pain for the developers."

Pavel acknowledged, "the incentive has already worked for MadWifi, which has landed in the wireless-2.6 repository under the name 'ath5k'. Still, there is a lot of work to do, and some features won't appear in the kernel driver soon, partly because they rely on the chipset features that still need to be reverse engineered. " In response to Pavel's original question, Dave Jones noted that Fedora kernels treat the development between a major release and the first release candidate as "rc0".

"I should be doing status reports, so here's my first cut at what is happening and what is going on so far. I'll try to do these every few weeks, and I also encourage the project managers of active projects to also do this," explained Greg KH, posting his October 16'th Status Report for the Linux Driver Project. He noted:

"Currently, I'm talking with about 3-4 new companies about more projects, and am working on a list of external modules that need to get cleaned up and added to the kernel tree that this project can help out with.

"But what we are really lacking right now is more companies involvement. If anyone can think of a way to drum up more company interest, please let me know."

Greg then offered a status summary of all six currently active projects, "here's the current projects, and what is going on with them." Drivers currently being developed by the driver project include, "3 i2c devices, a VOIP gateway driver, USB/PCI driver for video timestamp device, highspeed datacapture device driver, and a video digital demodulator driver" Another project is listed as focusing on cleaning up the existing USB driver.

"I have ported [the] adutux driver for [the] ADU series device list from 2.6 to 2.4," Vitaliy Ivanov announced on the Linux USB development mailing list. 2.4 maintainer Willy Tarreau explained that while the backport looked good, as a rule it was best to not merge new drivers into the stable 2.4 branch of the Linux kernel, "2.4 is currently used by people who already are in 2.4 and cannot/do not want to switch, and by people who are looking for close to zero maintenance. Drivers are often a reason to switch away from 2.4, but not to stay in 2.4."

One of the arguments for merging the driver into the mainline 2.4 tree was so it would then be added to the various distribution kernels. Pete Zaitcev explained that this wasn't the way it worked with enterprise kernels, "at least in case of RHEL, such backports never were automatic. In any case, RHEL 2.1 and 3 do not receive new drivers anymore. We only do bugfixes if something comes up. Realistically speaking, 2.4 kernels are just too old for anyone to use." Willy did agree to consider merging the driver if Vitaliy wanted to step up as the official maintainer for the 2.4 backport.

Jeff Garzik posted a series of five patches for the forcedeth driver which he described as, "several proposed updates for testing". Forcedeth is a GPL'd driver for the Ethernet interface of the NVIDIA nForce chipset, originally merged into the 2.4.26 and 2.6.5 Linux kernels. Jeff noted two main goals for the patches:

"1) move the driver towards a more sane, simple, easy to verify locking setup -- irq handler would often acquire/release the lock twice for each interrupt.

"2) to eliminate a rarely used, apparently fragile locking scheme that includes heavy use of disable_irq(). this tool is most often employed during NIC reset/reconfiguration, so satisfying this goal implies changing the way NIC reset and config are accomplished."

Jeff explained that he was looking to get the changes tested, "these are intended for feedback and testing, NOT for merging." He went on to explain that one of the changes included two independent napi_structs, one for receiving and one transmitting, "I feel TX NAPI is a useful tool, because it provides an independent TX process control point and system load feedback point. Thus I felt this was slightly superior to tasklets. But who knows if this is a good idea? :) I am interested in feedback and criticism on this issue."

Roland Dreier posted an updated overview of his InfiniBand driver merge plans during the upcoming 2.6.24-rc1 merge window. The InfiniBand driver was first merged into the 2.6.11 Linux kernel. Roland noted, "since 2.6.23 still isn't out, and I've managed to reduce my patch review backlog a bit, it's probably a good idea to give another update about what I have queued for 2.6.24 already and what I hope to get to before the merge window opens." His description of the upcoming merge queue is broken into three sections, one for each subdirectory within drivers/infiniband. In addition to listing all patches intended for 2.6.24, Roland also listed two issues that would most likely wait for 2.6.25:

"1) Multiple CQ event vector support. I haven't seen any discussions about how ULPs or userspace apps should decide which vector to use, and hence no progress has been made since we deferred this during the 2.6.23 merge window.

"2) XRC. Given the length of the backlog above and the fact that a first draft of this code has not been posted yet, I don't see any way that we could have something this major ready in time."

"Sorry for the very long delay in getting this project back up off the ground. When I first announced it back in January, I never expected it to be so popular. Unfortunately, it ended up being pushed way back on my priority list as I had to deal with my day job at Novell first, then my Linux kernel development, then with any spare time left over, this project," Greg KH announced on the newly created Linux Driver Project Developer mailing list. He noted the project's official web page and explained:

"The good news is that this has now changed. As of today, Novell is sponsoring me to work on this Linux driver project as my first priority. This means I will have the time and resources to commit to managing the different developers and driver projects as part of my daily job."

The Linux Driver Project was originally announced in January of 2007.

"It doesn't seem to pull any dependency nor affect any other external piece of code unless I'm missing something, so it's a perfect example of what we've been discussing back then: there is just no point not merging it at any time right ? :-)" Benjamin Herrenschmidt summarized his request that the iwl4965 driver be merged into the 2.6.23 kernel late in the release cycle, outside of the standard two week merge window. John Linville answered, "it is queued for 2.6.24. I'm not even sure it was originally posted in time for the 2.6.23 merge window, but even if it was there was a lot of opposition to merging it until fairly recently. In fact, I'm sure there are still some wireless developers that are less than happy about merging it now." When asked what the opposition was about, he referred to a discussion on the netdev mailing list and explained:

"There have been a lot of spats about how functionality has been partitioned between the driver and the firmware, issues with how the driver tries to do things that either ought to be in mac80211 or not done at all, and some random complaints about ugliness like '#include "../../../net/mac80211/blah.h"', etc. There is still plenty of work to be done on this driver, but as you point out we are better-off with it in the kernel than with it out."

Greg KH posted three emails titled State of the Linux Driver Core Subsystem, State of the Linux USB Subsystem, and State of the Linux PCI Subsystem, noting that for each there were no known regressions then going on to list which patches were bound for the upcoming 2.6.24 kernel. Greg pointed out that there were a large number of open bugs against the USB subsystem, "yeah, there are way too many there, I've been really slack in trying to work through them. If anyone wants to help out, feel free :)" He continued:

"Note, there are over 100 patches in the USB queue, so I might have missed a few things in reviewing them by hand right now. If I failed to describe your patch that is already in the queue, and you feel it is important for everyone to know about, please feel free to add to the above list. I did not purposefully mean to exclude anything, merely try to summarize things"

Stefan Richter posted the IEEE1394 subsytem and FireWire subsystem TODO lists noting, "it seems also appropriate to disclose the current manpower behind FireWire driver development and maintenance. There are just two people who regularly work on the drivers: Kristian Høgsberg (author and maintainer of the new firewire subsystem, in the past also involved with the old ieee1394 subsystem) and me (co-maintainer of both the new and old subsystems). But we both have a lot of other projects going on at the moment."

The current IEEE1394 subsystem is available for the 2.6 and 2.4 kernels, also known as the Linux1394 driver stack. Kristian Høgsberg started development of the new FireWire stack, nicknamed "Juju", in December of 2006. The Linux1394 website notes, "when the new stack's initial bugs and missing features have been addressed, it is anticipated that the old driver stack (ieee1394, ohci1394, pcilynx, raw1394, video1394, dv1394, sbp2, eth1394) will be scheduled for removal from the mainline kernel sources. (There is by the way no replacement for pcilynx planned at the moment, because this controller has become very rare.) The main reasons to replace the old stack by the new one are: lower code footprint, hence lower maintenance cost; better security; consolidation of the currently three or four different userspace ABIs (depending on how you count them) into a single, modern ABI."

Keith Packard announced the availability of drivers for Intel's 965GM Express Chipset. Jeff Garzik responded, "great news. Here's hoping that Intel produces a standalone video card eventually, to further take away market share from closed source competitors." In Keith's announcement he explained:

"The Intel® 965GM Express Chipset represents the first mobile product that implements fourth generation Intel graphics architecture. Designed to support advanced rendering features in modern graphics APIs, this chipset includes support for programmable vertex, geometry, and fragment shaders.

"Extending Intel's commitment to work with the X.org and Mesa communities to continuously improve and enhance the drivers, support for this new chipset is provided through the X.org 2.0 Intel driver and the Mesa 6.5.3 releases. These drivers represent significant work by both Intel and the broader open source community."

Kristian Høgsberg posted an update on the effort to rewrite the Linux kernel FireWire stack [story] explaining, "as you may know, we've been working on a new FireWire stack over on linux1394-devel. The main driver behind this work is to get a small, maintainable and supportable FireWire stack, with an acceptable backwards compatibility story." He went on to request the stack's inclusion in the mainline kernel, listing the following highlights: the new FireWire stack "has been in Fedora rawhide (development branch) and -mm for 3 months, will be shipping in Fedora 7; backwards compatible at the library level, existing user space libraries have been ported to use the new user space interface; less than 8k lines of code compared to 30k lines of code in the old stack, and a similar size reduction in the sizes of the .ko's; no kernel threads, compared to one subsystem thread and one thread per FireWire controller in the old stack; one user space interface to support zero-copy scatter-gather streaming, as opposed to the old stacks 4 (was 5) different streaming interfaces; per-device device files, letting userspace set up more finegrained access control, such as preventing direct access to FireWire storage devices."

Kristian went on to note the following regressions when comparing the new stack to the old: "eth1394 not ported over, there is nothing preventing this from being done, though, but there's a couple of infrastructure bits that aren't done yet; no support for the PCILynx chipset, nobody has this chipset anymore, and the pcilynx driver in the old stack is bit-rotting anyway; some SBP-2 (storage) devices fail after significant amounts of IO, not clear what the problem is, but I can reproduce it here and am working on fixing it." Regarding his plans going forward, "what I'd like to propose is that we carry both the new and the old stack in mainline for a few releases. Once we've reached a satisfactory level of stability and worked through what regressions there may be, we can consider deprecating the old stack."

James Ketrenos announced a new 80211 based driver for the Intel PRO/Wireless 3945ABG network connection adapter, "this new driver uses the new d80211 subsystem previously only available as part of the wireless-dev tree." An earlier incarnation of the driver code was much criticized for its inclusion of a userland binary-only daemon [story], prompting the OpenBSD project to create their own blob-free driver for the card [story]. "The [new] iwlwifi driver for the 3945 does not require the user space daemon, but does require a new microcode image," James explained, "over the past year we were able to make the necessary changes to the microcode used with the 3945 such that we were able to remove the regulatory daemon."

When the question was asked if the driver was going to be pushed for inclusion into the mainline kernel it was noted, "hmmm...I think we need to spend a cycle or so in -mm. 2.6.22 seems more likely for mainline." Pavel Roskin suggested, "iwlwifi is surprisingly good for a just announced driver. It worked for me from the first attempt, and that's the first d80211 driver to do so. In my opinion, it should go to wireless-dev as soon as possible so it can go to -mm together with other drivers."