DKMS and weak-modules (kABI)

[Matt Domsch]

On Fri, Feb 09, 2007 at 11:20:27AM +0200, Panu Matilainen wrote:
> 
> Hi,
> 
> I've been converting our kernel module packages over to dkms at work 
> and simply loving it for the most part :) One of the "issues" I'm having 
> with it is that while automatic compiling on boot is very, very nice, it 
> can take significant amount of time and it'd be nice to skip it when 
> it's not strictly needed. Enter kABI (and RHEL5 beta which is where I'm 
> testing this stuff).
> 
> I have a patch to make dkms call /sbin/weak-modules after installing a new 
> module, and that works as expected, the newly built+installed dkms modules 
> get linked to all compatible kernels. So far so good, but here is where 
> the trouble starts:
> - the module dkms just built now potentially exists in several kernel 
> versions, but dkms doesn't know about it
> - when booting to a new kernel which is covered by weak-modules 
> symlinking, dkms thinks an original module exists in that kernel, and then 
> goes on to build and install its modules anyway, making backups of the 
> symlinks basically :) and undoing the whole purpose of the symlinks
> - when the above happens (original modules exist) dkms_autoinstall seems
> to exit with an error code making the condition look far worse than it 
> actually is
> 
> Various workarounds to avoid needlessly rebuilding are possible and 
> easyish, but I suppose optimally dkms should know about links created by 
> weak-modules and keep record of them in its db so it can *really* handle 
> them and show correct status output etc.
> 
> Any thoughts on how to best handle this? I'm willing to do (much of) the 
> work once we agree how it should be done.
> 
>  	- Panu -

First, thanks for looking into this.  It's been on my TODO list for
way too long.  Jon Masters, I, and a few others spoke at FUDcon last
weekend about ways forward.  I need to get a RHEL KMP.spec file
included in DKMS so that 'dkms mkkmp' will build RHEL-looking KMPs
(like it already does for SuSE).  That shouldn't be hard though.

As for weak modules, you're right, DKMS never expected all those
symlinks.  I suspect the proper thing is for DKMS to see that the file
it's going to replace is a symlink, not make a backup copy of it,
and simply not know anything about it at all.  It's handled by
weak-modules, not by DKMS then.

I'm leery of following the symlinks and replacing the underlying
target (which is probably built for a kernel different than the one
you just asked DKMS to replace modules for).  That doesn't seem like a
good idea.


We discussed making a new plugin-aware app that /sbin/installkernel
can invoke, and to plug in DKMS there. That way on new kernel install,
DKMS's autobuilder can be run (rather than having to wait for
initscripts after reboot).  That way the autobuilder can be used for
modules that would land in the initrd too.


The whole build-and-compare step is a bit painful too.  We do it
because at the end of compilation we get a srcversion field out of the
resultant module.  But, as srcversion isn't calculated by a real
preprocessor but by a little C program called 'sumversion' in Kbuild,
I suspect we could get Kbuild to generate a srcversion for us without
doing the whole compilation, and could then skip real compilation.
Could even eliminate the need for a toolchain on the system then if
that tool were already in the kernel-devel package.  Hmmm...
sumversion takes as input dir/.file.o.cmd, which is generated by
compiling the .c into a .o.  Annoying. Need to think about that some
more.


Would love to see your patches.

Thanks,
Matt


-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com