DKMS and weak-modules (kABI)

[Panu Matilainen]

On Fri, 9 Feb 2007, Jon Masters wrote:

> On Fri, 2007-02-09 at 09:34 -0600, Matt Domsch wrote:
>
>> First, thanks for looking into this.
>
> Yup. Thanks Panu - I've been meaning to take a look too...but you know
> what it's like :-)
>
>> 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.
>
> I'm happy to help out as needed.

Me too...

>> 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.
>
> Yeah, I'd just ignore symlinks in general.

Leaving symlinks alone is the first step, but there are more nasty details 
to it than that. The more I look into it, the more I think that DKMS needs 
to be be really aware of what's going on with the symlinks and who they 
belong to.

For example
1) we have a kernel x.y.z, and a dkms managed module for it installed
2) we install abi-compatible kernel x.y.z+1 kernel
3) we end up with the module symlink in x.y.z+1/weak-updates/
4) run dkms_autoinstaller on x.y.z+1 and it complains about kernel
    source not installed and errors out
5) an observant user looks into it and wonders what the heck is going on:
    'dkms status' doesn't show the new kernel, building it failed yet
    things still work


4) and 5) are kinda silly, dkms should notice that a module (ultimately 
built and managed by it) already exists and be happy. Upgrade-scenario is 
then another thing, I haven't really even considered it, but assuming dkms 
kept record of weak-updates symlinks I suppose that should "just work" 
through the version tracking it does.

Granted, the situtation could be much worse than "things still work" :)

>> 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.

This is one part of the picture: at the moment those symlinks can be 
created behind dkms' back (just by installing a new abi-compatible 
kernel). To have dkms know about those symlinks, AFAICT it needs to locate 
them by brute-force on each run. Since that work needs to be done on each 
run anyway, there's not much point in recording them in dkms database.

Locating those symlinks and making them look like "status installed" 
(although I suppose it should be not really "installed" but some special 
"kabi link installed" status instead) for dkms doesn't sound like much 
work, but my Python-spoiled brain is having some trouble digesting the way 
dkms works :)

Attached is the little patch I have at the moment to call weak-modules 
after installing / removing modules. It's probably .. if not totally wrong 
(it does get those symlinks generated and removed :), then at least very 
non-optimal. I'm not really sure about the removal part sanity, and 
installation has at least one annoying issue: weak-modules is getting 
called once per each module, which in turn causes *lots* of mkinitrd 
building because weak-modules loves to rebuild a new initrd each time it's 
called. For example madwifi consists of 11 separate modules, this means 11 
mkinitrd's created and thrown away. Ick. It's probably fixable by moving 
the weak-modules calls to another spot, but haven't bothered with it while 
we're discussing the approach to this.

It would help a bit if weak-modules had an option to disable the 
mkinitrd-rebuilds as dkms has its own mechanism for knowing 
whether to update initrd for a given module or not.

 	- Panu -
-------------- next part --------------
--- dkms-2.0.13/dkms.orig	2006-11-03 11:19:56.000000000 +0200
+++ dkms-2.0.13/dkms	2006-11-03 11:26:39.000000000 +0200
@@ -1049,6 +1049,11 @@
 	mkdir -p $install_tree/${kernelver_array[0]}${dest_module_location[$count]}
 	cp -f "$base_dir/module/${dest_module_name[$count]}$module_suffix" "$install_tree/${kernelver_array[0]}${dest_module_location[$count]}/${dest_module_name[$count]}$module_suffix"
 
+	# add to kabi-tracking
+	if [ -x /sbin/weak-modules ]; then
+		echo "$install_tree/${kernelver_array[0]}${dest_module_location[$count]}/${dest_module_name[$count]}$module_suffix" | /sbin/weak-modules --add-modules --verbose 
+	fi
+
 	count=$(($count + 1))
     done
     
@@ -1342,6 +1347,12 @@
 		    echo $""
 		    moduleconfig_remove "${kernelver_array[0]}"
 		fi
+		# remove kabi-tracking if last instance removed
+		if [ -x /sbin/weak-modules ] && 
+		   [ `$0 status -m $module -v $module_version | \
+			grep -c "installed"` -eq 1 ]; then
+		    echo "$install_tree/$1${dest_module_location[$count]}/${dest_module_name[$count]}$module_suffix" | /sbin/weak-modules --remove-modules --verbose
+		fi
 	    fi
 	    count=$(($count+1))
 	done