Support non-DKMS modules built with a vendors external tools

[Lantizia]

Many proprietary and third-party products ship kernel modules but do not use DKMS. Instead, they provide their own build utilities which must be manually rerun after every kernel update.

Examples include products that generate modules via vendor-provided scripts (e.g. vmmon and vmnet with VMware), build tools, or even remote compilation services (R1Soft's hotcopy). Often these vendor supplied scripts are hot garbage, but when using the right arguments they are just useful enough to get the finished module binary to exist on the filesystem... despite not usually being properly installed, re-installed (after a new kernel is installed) or signed.

For example... VMware Workstation wants two modules vmmon and vmnet. But their scripts forget to sign them and so won't work with Secure Boot. You can instead preemptively build these modules yourself after installing their software, but before running their software for the first time. That way their software doesn't attempt to build and load modules itself on first run (and usually failing)...

echo vmmon vmnet|xargs -n1 sudo vmware-modconfig --console --build-mod

sudo depmod

[ "$(mokutil --sb-state 2>/dev/null)" = "SecureBoot enabled" ] && echo vmmon vmnet|xargs -n1 modinfo -n|xargs -n1 sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /var/lib/shim-signed/mok/MOK.{priv,der}

sudo /etc/init.d/vmware start

In these cases, DKMS can still provide value by handling automatic rebuilds after a new kernel is installed (as these vendor-specific scripts don't call themselves automatically like DKMS does) while delegating the actual module generation to the vendor-supported mechanism. This also means modules get properly signed via the same mechanism as DKMS too for secure boot.

This could be approximated with DKMS currently by invoking the vendor's build utility...

sudo mkdir -p /usr/srv/vmware-modules-0

cat <<'EOF' | sudo tee /usr/src/vmware-modules-0/dkms.conf
PACKAGE_NAME="vmware-modules"
PACKAGE_VERSION=0
MAKE[0]="make"
BUILT_MODULE_NAME[0]="vmmon"
DEST_MODULE_LOCATION[0]="/kernel/misc"
BUILT_MODULE_NAME[1]="vmnet"
DEST_MODULE_LOCATION[1]="/kernel/misc"
AUTOINSTALL="yes"
EOF

cat <<'EOF' | sudo tee /usr/src/vmware-modules-0/Makefile
KERNELRELEASE ?= $(shell uname -r)
KDIR ?= /usr/lib/modules/$(KERNELRELEASE)/build
PWD ?= $(shell pwd)

TARGETS := vmmon vmnet
LOCAL_MODULES := $(addsuffix .ko, $(TARGETS))

default: modules
install: modules_install

modules modules_install clean: $(LOCAL_MODULES)

%.ko:
	vmware-modconfig --console --build-mod -k $(KERNELRELEASE) $* $(shell vmware-modconfig --console --get-gcc) $(KDIR)/include build
	mv $(KDIR)/$@ $(PWD)
EOF

sudo dkms --all remove vmware-modules/0

sudo dkms install vmware-modules/0

Now the above works... but it has got me wondering a few things...

• The version number of '0' is clearly just a placeholder as I needed to put a version number in or it wouldn't work. I think we need a way of just stating the versioning is handled externally, especially for modules where it's hard to establish a specific version number.
• Currently DKMS can't know if a newer module exists that might be advantageous to update to (e.g. available to download/generate online pre-compiled, or compile locally)... so it's up to the user to re-run some DKMS commands to update it manually. This isn't too much of an issue... as this usually occurs when the software related to the module is upgraded manually too anyway, which prompts the user to think about that.
• Ignoring the module 'versioning' issues above... this does at least work as-is to automatically rebuild modules when there are kernel upgrades... which is at least a big annoyance fixed... and was the main point of doing this!
• The Ubuntu/Debian-version of DKMS seems to put the modules in /updates/dkms and ignores DEST_MODULE_LOCATION ? It might be handy if it didn't as that way you can specify the location a vendors external build script would put them (e.g. vmware-modconfig used /misc) by default... without having to them move them.
• But I doubt the file path of a module matters (e.g. my guess is VMware checks a module with the right name is loaded, not where it got loaded from from) so not a big issue?
• I guess it's possible some software might somehow know if the module you've got loaded is out of date (maybe via SRCVERSION that shows in modinfo)... so at this point there might be an issue where it goes off half cocked compiling it's own... and then you end up with two modules of the same name being loaded from two different paths (e.g. in both /misc and /updates/dkms). Not sure if there is a way to prevent this... or prefer (when two modules of the same name are trying to be loaded) the DKMS managed one?

[github-actions]

This issue has been automatically marked as stale due to inactivity. Please try to reproduce on the latest version of DKMS and update with any up to date information.

[Lantizia]

I've tried to rephrase this as less of a question, and more as a feature request for a documented way to have DKMS work with external build systems.