On 2020-03-26 15:13, Danny Milosavljevic wrote:
Hi Brice,
On Thu, 26 Mar 2020 14:34:03 +0000
Brice Waegeneire <br...@waegenei.re> wrote:
First I was expecting the packages in `kernel-loadable-modules' to use
the
`kernel' field as their kernel input or to have a simple procedure to
do
so. Otherwise you get a “Specified Linux kernel and Linux kernel
modules
are not all of the same version”. It makes it more difficult that it
needs
to be to write composable configurations; IOW why would I want to use
a
module built with a different kernel that the one I'm specifying in my
`operating-system'.
Because packages are modular, changing the build system can only be
done
retroactively by a procedure. We could totally do that but it would
make
the kernel-loadable-modules field more magical and more difficult to
debug.
Also, I guess it would hard-code linux-module-build-system for those
(right now you can use whatever build system you want). Do we want it
anyway?
And last issue, we are missing a service to load module manually when
they
can't be auto-loaded as it's the case with `ddcci`[1]. I have managed
to
solve this one by writing my first service
`load-kernel-modules-service'.
What can I improve before submitting it as a patch -- except the
missing
documentation?
I think that things should be described by nouns and actions should be
described by verbs.
So "load-kernel-modules-service" sounds really wrong to me.
Maybe "kernel-module-loader-service"?
Others don't care so much because Scheme kinda erodes the boundary
anyway.
Otherwise looks good to me.
I guess it could be nice to be able to extend this service from other
services
using (service-extension load-kernel-modules-service-type '("module1"
"module2")) or something.
