Hello Guix, Not too long ago, the linux-module-build-system was introduced. I ran into some code in the wild written by Alex Griffin that defines a shepherd service that does the following for a given kernel-module package:
- set the LINUX_MODULE_DIRECTORY environment variable to <out>/lib/modules - call modprobe on the .ko file (without .ko) I have verified this way of loading modules to work, but was wondering whether we should rather provide a `out-of-tree-kernel-module' service of sorts to do this. To resolve out-of-tree kernel module dependencies, I guess we would need to construct a union of all outputs so we can pass along one value for LINUX_MODULE_DIRECTORY that contains all out-of-tree modules that might be needed for one invocation of modprobe. Another issue is working with custom kernels; Alex' approach allows one to override the module package by providing an expression that resolves to a package object, which can use guile's `(inherit my-module)' approach in combination with `substitute-keyword-arguments' to do override the `#:linux' argument. This works and has the benefit of being pretty explicit in defining what we want to happen. The drawback is that one could possibly try to load a module that was built against a different kernel version than the one in your operating system expression. Is there a way by which a service can refer to the e.g. `operating-system-kernel' of the operating-system it is embedded in? - Jelle
