DKMS

[tmetro-blu-5a1Jt6qxUNc at public.gmane.org (Tom Metro)]

Jarod Wilson wrote:
> Tom Metro wrote:
>> I've been hoping that someone would put together a DKMS config to 
>> automate the rebuild.
> 
> In theory, if your script were in /etc/kernel/postinst.d/, it should get
> run automagically after a kernel upgrade. 

Sounds promising.

Perhaps /etc/kernel/header_postinst.d is a more appropriate location, if 
the build only depends on the headers.

How does the script determine which kernel it should be targeting? 
(Presumably it is being invoked while you are running kernel version X 
for an upgrade to version Y.)

Lets see...
% cat /etc/kernel/postinst.d/dkms
   #!/bin/bash

   # We're passed the version of the kernel being installed
   inst_kern=$1

   [ -x /etc/init.d/dkms_autoinstaller ] && \
     /etc/init.d/dkms_autoinstaller start $inst_kern

   exit 0

That answers that question.

I haven't looked at it, but I'm assuming the Alsa build script I'm using 
just targets the currently running kernel version, as you run it post 
boot and don't explicitly specify. (Which then requires a second reboot 
to get working sound.) So it'll need to be tweaked to take the kernel 
version as a parameter.


> You'd want a corresponding removal script in /etc/kernel/prerm.d/ too.

That would just clean up any installed .ko files?


> Both Ubuntu and Fedora support this, more or less at the request of
> Dell to allow dkms to trigger a module rebuild after a kernel
> install...

I see:

% ls /etc/kernel/*
/etc/kernel/header_postinst.d:
dkms*

/etc/kernel/postinst.d:
dkms*

/etc/kernel/prerm.d:
dkms*


Looks like Ubuntu borrowed from Fedora :-)
In /etc/init.d/dkms_autoinstaller:
   [...]
   kernelver_rpm=`rpm -qf "/lib/modules/$kernel" ...
   if ! arch=`rpm -q --queryformat "%{ARCH}" "$kernelver_rpm" ...
   [...]


On second look, DKMS may not be all that complicated. You dump your 
source in /usr/src/<module>-<module-version>/, and under that place a 
dkms.conf file. The minimal set of variables needed in dkms.conf is 
something like:

DEST_MODULE_LOCATION[0]="/kernel/drivers/something/"
AUTOINSTALL="yes"

which assumes that <module> (specified below) is the name to use in 
/etc/modules.conf, and that 'make' is the command to build the module 
(as well as a pile of other assumptions).

Then you run 'dkms add -m <module> -v <module-version>' to get it added 
to the DKMS tree, where in theory it'll get rebuilt when triggered by 
the above script.

dkms.conf is actually a shell script, and gets passed (sourced with) 
$kernelver, among other things, and it's up to you to make use of it, 
say by declaring a custom make command. They suggest:
MAKE="make  all  INCLUDEDIR=/lib/modules/${kernelver}/build/include"

Given the expectation of having the module version in the path to the 
source, it could be a bit trickier to deal with a situation where you 
are downloading the latest version of a module just prior to building 
it. Unless you can leave the version unspecified or it wouldn't break 
anything to leave it on some static number. In which case a PRE_BUILD= 
variable in dkms.conf could point to a download script.

It'd be no big deal if you had an asynchronous process doing the 
download periodically, as it could just run 'dkms add ...' after 
downloading a newer version. I assume DKMS will only use the latest, or 
maybe it is up to you to call 'dkms uninstall ...' for the old version?

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/