Hm, need to remember to use this more often...
Another year gone by...
Let's keep this simple:
That's a pretty good year...
- Ported the i2c/sensor code to 2.6 and got it in the tree.
- Took over the maintainership of I2C and PCI in the kernel.
- Solved the Linux device persistant naming problem with udev
- Got a zillion patches into the kernel tree.
Wow, it's been forever, but I'm stalling while I should be working on my linux.conf.au paper...
Zaitcev thanks for that USB patch. It was one of those things that I always knew was not quite right, but never bothered me enough to fix properly. Unfortunaly, there's probably lots of tiny pieces of the kernel that exist like that.
And thanks for keeping that broken patch out of Red Hat, I've had to defend not taking that patch too many times, even from people at work, with them pointing to SuSE as a reason to accept it...
Bah, back to the paper...
First two of us get called an axis, and then this picture from OLS 2002 gets out, finally people are realizing...Been playing with Movable Type so as to have a blog on my own site. Pretty fun, and much nicer than the hack of scripts I used to have that I used a long time ago to try to keep a log of what I was doing.
Finally got out lots of PCI core patches today. Problem was they touched all of the different archs code, so it took quite some time trying to fix up everything, luckily I didn't have to do the majority of the work :)65 patches in 48 hours, I think I need a rest this weekend away from the computer...
Ahh goingware is
looking at doing embedded work.
I started out doing embedded programming, and over the years realized that I was doing OS programming (right on the hardware, size restrictions, dealing with nasty, undocumented electronics, etc.) and started playing with Linux drivers as I saw somewhere I could help out. Flash forward to today, and I'm doing pure kernel work (but still dealing with the same constraints of embedded work.) In short, if you're comfortable writing kernel driver code, writing embedded code is a very short step.
Unfortunately, I second Zaitcev's statement about embedded programmers personalities and the general state of the environment in which they work. Typically you are working at a hardware based company, and have to live with design decisions made by people focused on the bottom line of product cost (remember, in production the firmware is free, and no one will recall the 6 months that it took you to get a beeper not to warble, even though they could have solved it with a 5 cent part in the design up front.) Because the company started out as a hardware environment, no one will understand the programmer's point of view, and you will be rarely brought into the hardware design process (or if you will, you will be ignored by them, as "they could produce the required code in this size EEPROM").
That being said, I loved it, but hey, I love writing Linux kernel drivers, what kind of a person likes doing that? :)
On a related note, I would like to publicly apologize to the Cygnus employee that I talked to at the 1997 Embedded Programmers Conference, and asked "what are you all doing here, I thought gcc was free?" I later realized what a jerk I sounded like, and I hope you are retired somewhere on an island due to the buyout by Red Hat :)
Bleah, I've not posted in forever, I'll try to do better next time...
Some things in the past:
OLS 2002 and the Kernel Summit
I went there all nervous about a proposal that Pat Mochel and I were making about driverfs and /sbin/hotplug. Basically we are wanting to move all of the existing device naming policy out into userspace. Well, our worse nightmare happened, everyone loved it and wants it right now :)
So now we're madly scrambling to get this done by 2.6. The main driverfs changes are now in the 2.5 tree and most of the core driver and now class changes are too. The PCI driver code is converted, and I've been posting patches to convert the USB core and driver code to the new model.
We might just make it yet...
The PCI Hotplug code is very broken in 2.5, and need to fix that up. Unfortunately we changed the pci_ops structure, so have a ton of patches to fix all of that up to get in before I can go back to the hotplug stuff.
2.4 is looking good, and the ACPI PCI Hotplug driver is working remarkably well (as well as ACPI can work.)
Zillion of patches sent to Linus to clean up __FUNCTION__ stuff last night. A ton more to Marcelo for 2.4 to backport the usb-serial stuff that has been in 2.5 for a while. Now that this is done, other backporting can happen, depending on what other people really want.
For some reason Linux Journal trusts me enough to write a column. This should be fun...
Catching up on stuff...
Things have been pretty quiet with the code lately. I've been playing with the ACPI version of the driver on a machine in the lab at work, and it is almost working properly... At least until the next ACPI update comes along and changes everything again :)
Made a new release of pcihpview this time making .rpm packages up to try to relieve all of the questions I had to answer about building the program from the tarball.
More tiny fixes all the time. I want to sync up with all of the USB changes in the -dj kernel, so will attempt to get that finished tonight.
Been having quite a run of articles published lately:
Hopefully they help people out.
- How the PCI Hot Plug Driver Filesystem Works is in the May 2002 issue of Linux Journal.
- Writing Portable Device Drivers is in the May/June 2002 issue of Embedded Linux Journal.
OLS looks to be a lot of fun this year. My talk is on the first day, so it will be nice to get it over and have fun going to the other talks. It looks like there are a lot of very good papers being presented.Misplaced anger
In working on syncing up the USB code in the -dj kernel into the latest 2.5 tree, I ran across this rant about the use of EXPORT_SYMBOL_GPL() in the kernel tree. As the first person who used this macro, I don't have much sympathy.
Also pay attention to the last sentence of the second to last paragraph of that page, I think that says it all :)
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.)
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!