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
