Is there any harm in loading a kernel module "twice" at boot time?

[gc-user]

Not being a dev I'm not sure which would be the correct way of doing this:

I created a template for a package that needs a kernel module loaded. I only noticed that because on one system another package was installed that needs the same module so the module was already running. On the second system this was not the case.

So, I could either make this other package a runtime dependency for the package in question - even though only the config file to load the kernel module is needed but the package itself is not - or instead let the install process create a config file for the first package to load the same kernel module, which leads to the situation that if both packages are installed independently there are now two config files (in /usr/lib/modules-load.d/) that load the same kernel module.

[18w]

Hi @gc-user,

No harm at all. I would ship your own config file, don't depend on the other package just for its conf.

At boot core-services/02-kmods.sh runs void-runit's modules-load. It reads *.conf from /etc, /run and /usr/lib/modules-load.d, keeps one file per basename, and passes all modules to a single modprobe -ab. If a module is listed in two files, modprobe just sees it twice. For an already loaded module modprobe does nothing and returns 0. That's also why it works on your first system already.

Only thing to watch is the file name. Name it after your package (<yourpkg>.conf), not after the module. If both packages ship the same path, xbps refuses to install the second one because of the file conflict. And if the same basename exists in /etc and /usr/lib, only the /etc one is read.

post_install() {
	vinstall ${FILESDIR}/<yourpkg>.conf 644 usr/lib/modules-load.d
}

Good luck with the template!

[gc-user]

Thanks @18w for your helpful reply!

That's essentially what I assumed as well. Both variants work and are probably both legitimate, but I wasn't quite sure if it was "bad dev practice" to have a kernel module being loaded "twice" - not really, but still.

As for the way to do it I just copied and modified the approach of the other package which essentially creates the config file through the template.