DKMS and weak-modules (kABI)

[Panu Matilainen]

On Mon, 12 Feb 2007, Panu Matilainen wrote:
>
> 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.

Duh, the above kinda completely misses the point while pointing to it. 
What I mean is that if dkms simply ignores the symlinks (as in not 
overwriting them) it still wants to *build* the modules because they're 
not in it's database. Which is what I want to avoid as much as possible, 
if I wanted it to rebuild whenever a new kernel is encountered I wouldn't 
be scratching my head over this :)

I think we need to teach do_status() to look for those symlinks for 
dkms-managed modules in all installed kernels and track them in memory for 
a given run (but probably not disk, as long as the links can change behind 
dkms' back), so that it can see a given module version was already built 
and available for kernel versions a, b and c (be it weak-modules symlink 
or real module).

Hopefully this time I managed to make a bit more sense :)

 	- Panu -