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

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"

"It turns out that USB devices suck when it comes to powermanagement issues :(" lamented Greg KH in posting some patches to handle USB autosuspend problems. He noted that the patches were intended for inclusion in the upcoming 2.6.23 kernel, "a number of patches have been submitted near the end of this kernel release cycle that add new device ids to the quirk table in the kernel to disable autosuspend for specific devices. However, a number of developers are very worried that even with the testing that has been done, once 2.6.23 is released, we are going to get a whole raft of angry users when their devices break in nasty ways." He proved an example, "it seems that almost 2/3 of all USB printers just can not handle autosuspend. And there's a _lot_ of USB printers out there..."

Later in the discussion, Linux creator Linus Torvalds commented, "in general, I think the USB blacklist/whitelists are generally a sign of some deeper bug." He continued on to point out a number of quirks in the USB layer that need to be addressed and added:

"We used to have a lot of those things due to simply incorrect SCSI probing, causing devices to lock up because Linux probed them with bad or unexpected modepages etc. I suspect we still have old blacklist entries from those days that just never got cleaned up, because nobody ever dared remove the blacklist entry.

"We should strive to make the default behaviour be so safe that we never need a black-list (or a whitelist), and basically consider blacklists to be not a way to 'fix up a device', but a way to avoid some really serious AND *RARE* error."