ZFS on Guix, again

[raid5atemyhomework]

Hi guix-devel,

I had some questions on the big ZFS guix bugpatches a week ago, and did not 
find any response, so I am back here pestering everyone.

Anyway:

* I am wary of calling the service type that accepts kernel modules as 
`linux-loadable-module-service-type`:
  * The equivalent existing `operating-system` field is 
`kernel-loadable-modules`.  Because `operating-system` is user-facing, we 
cannot rename it to `linux-loadable-modules`, thus leading to a naming 
inconsistency (the `operating-system` field is `kernel-loadable-modules`, the 
service type that adds items to that field is 
`linux-loadable-module-service-type`).
  * Just because Guix only supports two kernels *now* and only one of them 
(`linux-libre`) supports loadable modules does not mean in the future Guix will 
not support *other* kernels with a concept of a loadable module (e.g. FreeBSD 
kernel).  So it seems premature to only name it `linux` loadable modules when 
the concept of a kernel-loadable module apparently also exists in other kernels 
(since OpenZFS itself can be compiled as an out-of-tree kernel module for 
FreeBSD, and there is nothing really preventing Guix from supporting FreeBSD in 
the future).
  * There is already an existing `kernel-module-loader-service-type`.  This is 
used to explicitly load kernel modules, which either have to be in the 
`kernel-loadable-modules` field of `operating-system`, or provided by extending 
with the new, inconsistently named `linux-loadable-module-service-type`.

Changing the name to `linux-loadable-module-service-type` means:

* We should deprecate `kernel-module-loader-service-type` and replace it with 
an equivalent `linux-module-loader-service-type`.
* We should deprecate the `operating-system` `kernel-loadable-modules` field 
and replace it with an equivalent `linux-loadable-modules` field.

In any case, I have some sketches below.

I want to create two new service types:

* `linux-profile-builder-service-type` which has configuration 
`linux-profile-builder-configuration`.
  * `linux-profile-builder-configuration` has fields:
    * `linux-libre` which is the `kernel` field of the `operating-system`.
    * `loadable-modules` which is the `kernel-loadable-modules` field of the 
`operating-system`.
  * This type is extensible.  `compose` is `identity`, `extend` is `(lambda 
(config extensions) ((apply compose identity extensions) config))`
    * In short, extensions of this service-type should return a procedure which 
takes the `linux-profile-builder-configuration` and modifies it.
  * This extend the root `system-service-type`, creating the `kernel` output.
* `linux-loadable-module-service-type`, which takes as configuration an empty 
list.
  * This type is extensible.  `compose` is `concatenate`, `extend` is `append`.
  * This has a single service extension:
    * Extends `linux-profile-builder-service-type` and if the configuration is 
not an empty list, extends the Linux-libre profile builder by a procedure that 
appends the list of kernel-loadable modules.

The above gives a separation of concepts:

* The `linux-profile-builder` builds the kernel profile for Linux-libre systems.
* The `linux-loadable-module-service-type` ensures that the kernel profile 
contains particular loadable kernel modules.

In the future there may be additional non-module things we can add to the Linux 
profile, so I think this separation is useful.

--

Another point I want to bring up is the use of `file-system-service-type`.

If we use `file-system-service-type` to extends the `file-systems` Shepherd 
service, then we need to add some kind of field to exempt the ZFS service from 
being added to `/etc/fstab`.

Note that ZFS expects there to be dozens of filesystems, and that creating and 
destroying file systems is just a "simple" `zfs create pool/file/system` 
command.  Each possible use or application may need to have specific tuning, 
thus each application may very well have its own file system with its own ZFS 
parameters specifically tuned for that application.

This is not a good fit with the `operating-system` mechanism in Guix, where you 
have to reconfigure the entire system just to add or remove file systems.

Nevertheless the ZFS still supports manual filesystem management, you just need 
to specify the `legacy` parameter, so it's still possible to use 
`operating-system` and its `file-systems` field to manage ZFS mounts, you just 
need to do `zfs create -o mountpoint=legacy pool/file/system`.  Though Guix 
still needs some modifications since the `device` would have to be 
`"pool/file/system"` and some parts of Guix attempt to search for a block 
device.

However, for the case where the user expects the "typical" ZFS style of 
managing file systems, we need to mount all the ZFS file systems and ensure 
that they aer all already mounted by the time `file-systems` Shepherd service 
is started.  This means we need to be able to extend the `requirement` of the 
`file-systems` Shepherd service.  And we need to do that without putting any 
extra `/etc/fstab` entries since for "typical" ZFS style of managing file 
systems, they are required to ***not*** be put in `/etc/fstab`.

* We can just create a separate `file-systems-target-service-type` that always 
accepts (list of) symbols that the `file-systems` Shepherd service will 
`requirement`.  Then `file-systems-service-type` can just extend that service 
type.  This is what I already originally did.
* 宋文武 proposed to instead make `file-systems-service-type` accept a 
heteregonous list of either symbols or `<file-system>` records.
  * Ludo' ***agreed*** with this.... but then says that mixing symbols and 
`<file-system>` records in the same list is bad design.  So... this is 
confusing.

There are two alternatives:

* Go with what I already proposed which I think is more general-purpose and 
cleaner (there is a separate service type that accepts symbols, and a separate 
service type that accepts `<file-system>` records, and the latter just extends 
the former).
* Don't make a separate service type, but now we need to add some kind of 
`fstab?` field to `file-system` so that the ZFS shepherd service that mounts 
ZFS file systems will not be included in the `/etc/fstab`.

I think overall that having lots of tiny service types that are then combined 
together fits the functional design of Guix better.  So I would strongly 
propose my original design rather than hacks on top of 
`file-system-service-type`.

Thanks
raid5atemyhomework