Re: ZFS on Guix

[raid5atemyhomework <raid5atemyhomework@protonmail.com>]

Hello Danny,

> I just wanted to say that I'm not ignoring your patch, I'm just not qualified
> to review it. I hope someone steps up to it--otherwise I can't really tell
> whether (mbegin %state-monad...) inside a random service procedure is a good
> idea.
>
> Then again, provenance-service-type does it and there it seems to be fine...


For ***this*** very specific case it is because of a random weirdness of `system-service-type`.

Specifically, the *value* of that service-type is an association list of filenames and their contained store values.  However, an ***extension*** of that service-type must be a monadic action that results in an association list of filename-contents.


Here is relevant code in `gnu/services`:

```scheme
(define (system-derivation entries mextensions)
  "Return as a monadic value the derivation of the 'system' directory
containing the given entries."
  (mlet %store-monad ((extensions (mapm/accumulate-builds identity
                                                          mextensions)))
    (lower-object
     (file-union "system"
                 (append entries (concatenate extensions))))))

(define system-service-type
  ;; This is the ultimate service type, the root of the service DAG.  The
  ;; service of this type is extended by monadic name/item pairs.  These items
  ;; end up in the "system directory" as returned by
  ;; 'operating-system-derivation'.
  (service-type (name 'system)
                (extensions '())
                (compose identity)
                (extend system-derivation)
                (description
                 "Build the operating system top-level directory, which in
turn refers to everything the operating system needs: its kernel, initrd,
system profile, boot script, and so on.")))
```

So *extensions* must be monads (due to `mapm/accumulate-builds` on the `mextensions`) but the raw value must be a simple non-monadic assoc list.

The patch moves some generated files ("kernel" and "hurd") from the value of the `system-service-type` to an extension of `system-service-type`, thus the extra `mbegin %store-monad`. It needs to be `%store-monad` since that is the monad used by the `system-derivation` function.

See:

```scheme
(define (kernel-builder-configuration->system-entry config)
  "Return the kernel and hurd entries of the 'system' directory."
  (mbegin %store-monad
    #;...))
#;...
(define kernel-loadable-module-service-type
  (service-type (name 'kernel-loadable-modules)
                (extensions
                 (list (service-extension system-service-type
                                          kernel-builder-configuration->system-entry))) ;; <-- OVER HERE
                (compose concatenate)
                (extend kernel-builder-configuration-add-modules)
                (description
                 "Register packages containing kernel-loadable modules and adds them+to the system.")))
```

So it is not just some "random service procedure", it is because that is the interface exposed by `system-service-type` for its extensions, extensions of `system-service-type` have to yield a monadic action.  `mbegin` is one of the simpler monadic actions.  It is also in the "correct place" as best as I can tell, since only service types in `gnu/services.scm` dare to extend `system-service-type`.

`provenance-service-type` does this as well because it *also* extends `system-service-type`.  This is basically done here simply because that is what `system-service-type` expects.

Thanks
raid5atemyhomework