Hi Brice,

On Thu, 26 Mar 2020 14:34:03 +0000
Brice Waegeneire <brice@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.