Integrate DKMS with OS's kernel updates

[jetojedno]

Hi,

I use DKMS to build the Nvidia drivers from the source, so obviously this needs to be repeated each time the kernel is updated. For me, it's not.

There are three things I think are needed for proper integration:

1. the module is built immediately following install of a new kernel
2. the module is included in the new initramfs image
3. the module and all associated DKMS build files are deleted as part of old kernels purge.

None of these things are happening.

Have I missed a config step, or do I need to install an extra package to integrate this properly?

Thanks
David

[arvidjaar]

There is no integration of kernel package with DKMS.

[jetojedno]

There is no integration of kernel package with DKMS.

It's not so much integration of the kernel package with DKMS but integration of the kernel package delivery and installation mechanism with DKMS (or, more exactly, DKMS with the kernel installation mechanism).

I'll have a crude hack at scripts to do that for myself, and if anyone has the knowledge, could they create an integration? I'm sure the last / zipp mechanism has the appropriate integration hooks.

Yours
David

[tsu2]

I have not heard that DKMS works for modules that are loaded into the initramfs unless perhaps the module is built dynamically on boot (GPU proprietary drivers used to do this,, AFAIK not any more) or require a re-boot. AFAIK DKMS is mainly useful for LKM (Loadable kernel modules) that are automatically loaded during the second stage of kernel loading or can be unloaded/loaded manually by a process or person.

And, DKMS is specifically designed and intended to update the kernel module automatically or from one description I've read "shim" the old module to the new, upgraded kernel so that no re-compilation is needed.

This should typically mean that whenever you want to install a new nVidia driver... yes it might be advisable to compile it with DKMS sot that...
Whenever the kernel is upgraded, your already compiled driver modules should continue to work without any attention.

In other words, if you compiled correctly, you shouldn't have to recompile just because the Linux kernel got upgraded.

Just out of curiosity, is there a reason why you might want to compile your nVidia drivers instead of installing pre-compiled drivers from teh nVidia repo?
(Assumes you're running a kernel distributed by openSUSE).

TSU

[arvidjaar]

integration of the kernel package delivery and installation mechanism with DKMS

Yes, I understand that.

You posted it for Leap 15.2 version. With Leap you do not really need DKMS at all. Leap kernel is guaranteed to preserve ABI (if it breaks it is a bug) so any kernel module will be usable with all future kernel updates, there is no need to rebuild modules, just make sure new kernel will find modules built for old kernel. And that is fully integrated in kernel delivery, you just need to build your driver as KMP (Kernel Module Package).

[tsu2]

Yes, I understand that.

You posted it for Leap 15.2 version. With Leap you do not really need DKMS at all. Leap kernel is guaranteed to preserve ABI (if it breaks it is a bug) so any kernel module will be usable with all future kernel updates, there is no need to rebuild modules, just make sure new kernel will find modules built for old kernel. And that is fully integrated in kernel delivery, you just need to build your driver as KMP (Kernel Module Package).

Not having heard that ABI is a replacement method for DKMS, I did a small search (there aren't very many results searching for the two together).

That's interesting if SUSE/openSUSE can guarantee that the LEAP kernel ABI won't change, I would expect that is possible only because the LEAP kernel backports patches to only a few kernels instead of adopting new upstream kernels. Maybe at least with LEAP a major conflict might have to be dealt with only every 12-18 mths when a version upgrade is released with a certain new kernel and I suppose new ABI standard, it surely wouldn't be feasible for Tumbleweed.

The other possible issue I see though is that the ABI might not cover the entire KLM interface interoperability, only a part. If that's true, then simply relying on a consistent ABI isn't sufficient to guarantee no problems for the life of that LEAP kernel.

Unless someone wanted to support only that specific LEAP version, I would instead suggest ensuring support for DKMS (would almost certainly minimize and possibly eliminate future related maintenance issues).

TSU