Supporting non-DKMS modules using a vendors external tools

[Lantizia]

This isn't a DKMS problem

So if that's enough for you to close this right now, then please do so. I just saved you a lot of reading :)

But it is a problem that DKMS might be able to ease for a lot of people (that 'might' is doing a lot of heavy lifting)

Since I've tempted you this far, I'll go on :)

Basically I get really annoyed when I see vendors such as VMware and R1Soft not use DKMS for their kernel modules. They instead have some other tool for managing their kernel modules... but they don't automatically run themselves when a new kernel is being installed.

So I've always thought about "linking" DKMS to their tools, so that technically their module was generated the vendor-supported way... but has all the benefits of DKMS automation.

This is an EXAMPLE SCENARIO of what I'm on about... (this isn't a VMware query!)

VMware Workstation seems to want to install two modules vmmon and vmnet. But unfortunately the scripts that comes with their software are written like hot garbage.. so they 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 that are already loaded...

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

So that got me thinking about just doing this within DKMS instead and I came up with this...

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 don't see the point in putting the version number of the VMware product (e.g. Workstation 17) as it's really the version of the individual modules that should matter... whatever they are? (maybe use SRCVERSION from modinfo?)
• Currently DKMS can't know if a newer version of the source code for the modules was installed by a VMware desktop product... (such as VMware Workstation)... so I guess it's just up to the user to re-run some DKMS commands to update it manually... not the end of the world (especially as they had to manually upgrade VMware Workstation anyway... as it's not like the upgrade occurred via an APT repo or anything similar).
• 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 the DEST_MODULE_LOCATION which tries to put them in /misc (and I picked that location... because that's where vmware-modconfig would normally put them)
• I doubt that any VMware product cares what path the modules were loaded from, so the above probably doesn't matter. I have a feeling any VMware product is just going to check that the modules, with the correct names, are loaded.
• Is any VMware product likely to check the version of the modules loaded? Then, at some later date... if it thinks they're out of date... and tries to automatically build new ones (with its own scripts)... they really would then end up in /misc and you'd have two pairs of them? (the other pair in /updates/dkms). Perhaps VMware uses the SRCVERSION field from modinfo to know if the loaded modules are out of date? Is this somehow useful?

Any thoughts on the general topic of using DKMS to link to external module generation utilities/scripts... please, let me know.

This isn't specifically about VMware at all. For example I'm also thinking about how I could do something similar with R1Soft.

Their 'Server Backup' / 'Continuous Data Protection' (CDP) / 'Hot Copy' products uses a module called hcpdriver. This is actually generated by their utility sending a copy of your kernel headers off to THEIR servers... so they generate the module and send it back to you! Paranoia much? and yes I have mentioned DKMS to them several times... as well as how there can't be anything too amazing to protect in the source code of the module, when MANY other backup vendors have modules for doing similar things... but they keep their source on Github :)

But yeah, thoughts welcome. I'll keep developing the idea... but perhaps anyone with more DKMS knowledge than me has some tips?