Catching up on stuff...
The IBM PCI Hotplug driver got submitted and got accepted into the 2.4 and 2.5 trees. Nice to see this code finally escape the lab and make it into the wild. Now if only someone would actually use the thing...
Gave lots of documentation to someone at Compaq about how the pcihpfs interface works, so hopefully they will produce some good docuementation about how to use it.
Am slowly plugging away at cleaning up the Linux USB kernel code in the 2.5 tree. Now urbs have proper reference counting, cleaning up loads of potential race problems. More importantly, it now keeps people from having long involved arguments about when it is ok to free up a urb from within a device driver.
I took advantage of this new interface to redo the visor driver, showing off how you can abuse the new model :) Reduced the size of the driver quite a bit and didn't seem to slow it down any.
My Linux Hotplug article finally got published in the April 2002 issue of Linux Journal. This time I remembered to include my email address, and the responses so far have been very nice.
I need to work on the dietHotplug code some more, and put out a new release of the main Linux Hotplug package, now that the debian developer has fixed a number of small issues in it. I also finally got the cvs archive cleaned up by moving the fxload program into a different directory. It only took about 3 weeks to get the sf.net admins to move the cvs files around (did I mention that I hate cvs?).
Nice to see that Linus and Marcelo are now using BitKeeper to do kernel development. I've been using it for over a year, and it's the only way I am able to say sane, juggling 3 different kernel trees.
I gave a short talk to people at work, and at OSDL about how to do kernel development with BitKeeper. I've put the slides up online if anyone is interested in some BitKeeper basics (the last two slides are kinda interesting to show how different people use it.
Actually, now it takes longer to make up changesets for Linus and Marcelo to pull into their repositories than it did to make up patches for them, but the advantage of being able to send them more than one chunk of patches per -pre kernel, and ability for the people who do the real work to get the proper credit, more than make up for any minor inconvience that I may have (this means no more "USB updates - Greg KH" change log entries when I only sent the patches on from other people.)