DKMS and weak-modules (kABI)

[Jon Masters]

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.

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

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

We'll hack something together *hopefully* for F7, but there are plans
for a much better solution in F8 and beyond. More on this another time.

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

I'm not so sure that's going to be possible since you need the output
from the real compiler...but I will also have a think too. One thing's
for sure - we'd need a compelling reason to change upstream for our
benefit :-)

Jon.