kernel-module-configuration-service for configuring kernel parameters

OpenSubmitted by Danny Milosavljevic.
Details
3 participants
  • Danny Milosavljevic
  • Ludovic Courtès
  • raid5atemyhomework
Owner
unassigned
Severity
normal
Merged with
D
D
Danny Milosavljevic wrote on 6 Jan 20:41 +0100
20210106204134.38e83db4@scratchpost.org
Hi raid5atemyhomework,Hi everyone,
@raid5atemyhomework, thanks for all the patches!
On Wed, 06 Jan 2021 15:57:19 +0000raid5atemyhomework via Guix-patches via <guix-patches@gnu.org> wrote:
Toggle quote (7 lines)> +@item @code{options} (default: @code{'()})> +A list of string options to pass as options to the ZFS module.
> +These will be put in a @file{/etc/modprobe.d/zfs.conf} file,> +for example setting this to @code{'("zfs_admin_snapshot=1"> +"zfs_trim_extent_bytes_min=0")} will create the following file:
Sure, but it would be better to create a way to configure those module parametersin Guix in a declarative way, first.
Your new kernel-loadable-module-service-type would be a good templateto write a kernel-module-configuration-service that can be extended byother services. The latter should allow users to parametrize the kernelin general via the operating-system form, and also allow services to extendsuch configuration (with merging, and conflict detection).
It would be used:
(1) To declaratively specify the contents of something like /etc/modprobe.d .It shouldn't even be called "/etc/modprobe.d"--it should also be in the storeinstead. This directory is only useful for non-Linux-builtins.
(2) If the "module" is built-in then the kernel command line must get theoptions instead. (in fact, it works as a kernel command line option alsoif it's a loadable module--so not sure we need /etc/modprobe.d at all--atleast at first. But there's probably a maximal length for the kernel commandline that we could exceed if we did that long term)
I know it's annoying that Guix doesn't have this facility already, but thetime to introduce an interface for /etc/modprobe.d and the kernel commandline for builtin modules is before other services introduce their ownad hoc way to create /etc/modprobe.d--like this tries to do here.
See also https://issues.guix.info/issue/42193for an earlier attempt (whichis already very far--but it has a bug somewhere). There's also already akernel profile thing like you wrote in that patchset.(Note that I would prefer there not to be a "LOAD?" in there because itconfuses loading the module (which is usually NOT started by user spacebut by the kernel on its own) and confguring the module (which has to bedone by user space because it's specifying policy, not mechanism))
Also, because the kernel usually loads loadable modules on its own (potentiallyreally early), /etc/modprobe.d has to be preset and known to the modprobeexecutable VERY EARLY (via environment variable MODPROBE_OPTIONS--see gnu/services.scm %modprobe-wrapper).
It is totally possible that some modules in the initrd need options, too(see load-linux-modules-from-directory for where this would need to go).load-linux-module/fd already accepts options and flags--but both are not givenon the call. For this, part of future kernel-module-configuration entries(the ones needed for modules in the initrd) should be copied into the initrd,too.
Then there's the handoff between initrd and main system. It would be badif the kernel tried and succeeded to load a module that is not in the initrdjust before the modprobe.d directory is set up (because it would be loadedwithout passing the options the user configured)--so that needs to be avoided.
@ludo: Could you help here?
Toggle quote (3 lines)> +@example> +options zfs zfs_admin_snapshot=1 zfs_trim_extent_bytes_min=0
Note:
This can be usefully put in a modprobe.d-like directory if zfs is a module, butnot if it's built into the kernel. But it can be put into the kernel commandline in both cases.
But I guess the ZFS Linux kernel module can't be built-in into the kernelanyway.
But that's a special case--in general, it's very much possible to make modulesbuilt-in.
Toggle quote (2 lines)> + ;; You'd think we could've used kernel-module-loader-service-type,
Definitely.
Toggle quote (3 lines)> + ;; but the kernel-module-loader shepherd service is dependent on> + ;; file-systems,
Yes--but why is that dependent on 'file-systems ? Is it because it needs /proc ?Or is it an oversight ? I would prefer to get rid of this dependency and thenuse kernel-module-loader-service-type.
Also, this manual loading of kernel modules is not supposed to be the way todo things in Linux. That a kernel module was compiled as a module isan *implementation detail*--so Linux should (and usually does) automaticallyload kernel modules the first time a device for them is accessed (after all,how would user space know whether something is compiled as a module orbuilt-in--that would be too much to ask).
Linux is not a microkernel, so the kind of modularily modprobe.d suggestsexists does not in fact exist in kernel space--even though Linux does a goodjob faking it: modprobe.d contains:
* "alias": a feature to configure aliases, with wildcards (only one level ofaliases allowed!)* "options" per module (also works for aliases with wildcards! That will be"fun" to map to Guix)* "install" in order to run some custom executable instead of loading themodule.* "remove" in order to run some custom executable instead of unloading themodule.* "blacklist" to ignore specific internal aliases of a module (that doesnot do what one would intuitively think!).
If the file name of the regular file under /etc/modprobe.d is not used foranything, then we can just have one file /gnu/store/*modprobe.d/guix.confin total in there.
Then there are sysctl kernel parameters--but those Guix already exposes viasysctl-service-type. But those should also be made able to be extendedby other services, and merge conflicts should be handled. For example, usersoften set net.ipv4.ip_forward=1 (for example via sysctl).
Thank you for all your effort to make ZFS work nicely in Guix.
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/2Em4ACgkQ5xo1VCwwuqX7VQf/bHxCWBZt0FXRb5E0zvb0AZVwMPajkYvOBjfXJC+XcMbgjP3FKNW7VLGKFakRsyWnVX6gtFPxUDImjnCIGcY5LGYuaHxnDR4CTqzDBb06LRAMeJ1YTIyr+j+SZO17TG4hZa+xWLqM6MUpfEwuc1I/b5o9oN39XJJLJAWJOdXMi2ZGwOKY8dpYhaDwzDPoOb3xHj9oDyXyWjOfb/8VK8bF8+L9Fzy3Bjt2WiG58j5jXpkYz9ZQe3zA1hbHzwFmmKqkFbL2gFhTxGWuQrp6x29T60lzBwUcjG58waCQee23TVFR9K/v7fvjrBalkHMS+9/Dc8FBIdzlHAbxj8/74qYkUQ===nYdc-----END PGP SIGNATURE-----

R
R
raid5atemyhomework wrote on 7 Jan 01:04 +0100
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)
pilwAVCb0NEG83BVTSEqXkLCNEvBBrnb-QyKV_9PoF4xuCjSXKuF-F3_L5lSOke5BRjagVrUoSzJCST1fkigF162f9j76K12jBraNMAj7E4=@protonmail.com
Hello Danny,

Toggle quote (8 lines)> See also https://issues.guix.info/issue/42193for an earlier attempt (which> is already very far--but it has a bug somewhere). There's also already a> kernel profile thing like you wrote in that patchset.> (Note that I would prefer there not to be a "LOAD?" in there because it> confuses loading the module (which is usually NOT started by user space> but by the kernel on its own) and confguring the module (which has to be> done by user space because it's specifying policy, not mechanism))
Looks like that patchset was merged in, so basically I can just depend on that? So the first patch in this patchset would be dropped?
Toggle quote (6 lines)> But I guess the ZFS Linux kernel module can't be built-in into the kernel> anyway.>> But that's a special case--in general, it's very much possible to make modules> built-in.
ZFS *can* be built-in to the kernel, Ubuntu does it. You can't distribute it like that (Ubuntu distributes it like that but presumably they have enough lawyers to muddy the waters so that they can get away with it), but as the documentation in this patch notes: the user has every right to do whatever they want on the machine they own, including build a Linux kernel that has ZFS built-in and run it, they just can't make that version available to somebody else.
So to go whole-hog, we would have a service that replaces the kernel package and inserts kernel module sources in-tree somehow, then compiles Linux-libre on the user's machine. That would probably be a lot more painful to install ZFS with (the user has to recompile the whole kernel at each update of either kernel or ZFS, whereas with a kernel module the user has to recompile just the kernel module), so maybe kernel module is still better overall.

Toggle quote (17 lines)> > - ;; You'd think we could've used kernel-module-loader-service-type,> >> >>> Definitely.>> > - ;; but the kernel-module-loader shepherd service is dependent on> >> >> > - ;; file-systems,> >> >>> Yes--but why is that dependent on 'file-systems ? Is it because it needs /proc ?> Or is it an oversight ? I would prefer to get rid of this dependency and then> use kernel-module-loader-service-type.
Dunno --- one VM I tested, I removed the `zfs-scan-automount` shepherd service from the `file-systems` target, and the VM still wouldn't boot, claiming a stack overflow (the same error which I got when I was still trying to use kernel-module-loader-service-type here). Or maybe I just got confused with which VM was which, testing VMs wasn't a stress-free vacation. I just want ZFS, because MD RAID5 ate my homework, this is getting tiresome...
One thing I notice about `kernel-module-loader-service-type` is that it's not instantiated in essential services, or indeed anywhere in Guix. A few services *do* extend it. But my **very rough** understanding is that if you're going to extend a service, it had better be instantiated *once* in the list of services.
In particular I note that the documentation for `kernel-module-loader-service-type` shows an example where it uses `service` to program the `kernel-module-loader-service-type`, not `simple-service`. This suggests to me that `kernel-module-loader-service-type` is broken because it's not in the list of essential services but is extensible. Maybe. It's designed as an extensible service, but isn't instantiated at default. Maybe that's what really bit me and not the shepherd circular dependency loop? *shrug*

Toggle quote (8 lines)>> Also, this manual loading of kernel modules is not supposed to be the way to> do things in Linux. That a kernel module was compiled as a module is> an implementation detail--so Linux should (and usually does) automatically> load kernel modules the first time a device for them is accessed (after all,> how would user space know whether something is compiled as a module or> built-in--that would be too much to ask).
So how do I get ZFS loaded? Note that the devices it targets are block devices and it needs to scan for block devices that are formatted for ZFS. Do other filesystems have some autoload rule?
Thanksraid5atemyhomework
L
L
Ludovic Courtès wrote on 10 Feb 16:47 +0100
control message for bug #45692
(address . control@debbugs.gnu.org)
87y2fv6i26.fsf@gnu.org
merge 45692 45703quit
L
L
Ludovic Courtès wrote on 10 Feb 16:47 +0100
(address . control@debbugs.gnu.org)
87wnvf6i1i.fsf@gnu.org
merge 45692 45643quit
?