The beginnings of dust ...

So, as you might have seen from previous posts … I couldn’t fix what was broke in DKMS. We have some customers that insist upon the functionality, and we can’t fix the tool. So, rather than trying to force them to rerun our driver update scripts, we are automating the process. The idea is to make the whole process as easy as possible. Most of the management bits are done, the build bits come tomorrow. But here is the beginning of dust (Driver UpdateS Tool). Its needed as the kernel shipped with RHEL is usually ancient with respect to drivers, and customers get real unhappy when their shiny new boxes are mute and forgetful. Which usually happens right after a kernel update. First peek at dust below. It is GPL v2. Will get it into our public repository soon (maybe a chance to start working with git?)

landman@lightning:~/dust$ ./dust.pl  --status --config=./dust.ini   --db=./dust.db
id   driver	module	kernel			version		state
landman@lightning:~/dust$ ./dust.pl  --add --version=1.2.10 --module=e1000e  --config=./dust.ini   --db=./dust.db  --path=./ --name="e1000e" --build="make"
landman@lightning:~/dust$ ./dust.pl  --add --version=2.3.8 --module=igb  --config=./dust.ini   --db=./dust.db  --path=./ --name="igb" --build="make"
landman@lightning:~/dust$ ./dust.pl  --status --config=./dust.ini   --db=./dust.db id   driver	module	kernel			version		state
1    e1000e 	e1000e 	2.6.32-25-generic   	1.2.10         	new
2    igb    	igb    	2.6.32-25-generic   	2.3.8          	new

The path is the path to where the source directory is located, and the build command is what you use to build/install it. We won’t do anything terribly fancy, assume you have a real simple script to write to

1. run make or equivalent
2. move the old module out of the way
3. put the new module in its place
4. run depmod
5. run mkinitrd / initramfs

Which curiously, is what most of our module build/install scripts do. Its real easy to write, and we will include some examples. The issue we found was the dkms wasn’t rebuilding the module on reboot. It was playing some games that caused havoc which resulted in the module not being correctly picked up, usually in the initrd build. I wasn’t able to trace it down. This system is not trying to do all the heavy lifting for you. It simply checks to see if the module that you have added into the system has been properly built for the kernel you just booted into. If not, it will execute something akin to the build and install script above. Since we know that this works correctly (you can debug the script outside of the tool, then hand the script to the tool), it will be much easier to debug this when there are issues. Now if there is sufficient interest, we can add in module backup, rollback, and even failsafe type scenarios. Right now I want something that works well. And dust.pl will get us there. Written in Perl, uses a few Perl modules from CPAN (only one not in RPM form now). We will build that RPM, as well as build the “compiled” version of the code. With Perl6 (eventually) this will be easier, but for the moment, we will use PAR::Packer to compile it.