[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#41180] [PATCH] Add cachefilesd service.
From: |
Mathieu Othacehe |
Subject: |
[bug#41180] [PATCH] Add cachefilesd service. |
Date: |
Mon, 11 May 2020 17:06:08 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Hello Jean-Baptiste,
Thanks for this service!
> - I gathered that #~ / #$ kinds of suspends evaluation / forces it -- is
> there documentation about this somewhere ?
#~ and #$ are related to the Gexp mechanism. It's documented here:
https://guix.gnu.org/manual/en/html_node/G_002dExpressions.html.
> - There's something that looks like a splat operator (only seen in
> conjuction with forcing evaluation in #$@) -- again i'd be interested
> in more documentation about this feature -- is this a guix-specific
> operator?
#$@ is a shortcut for ungexp-splicing. It's also documented in the link
above. It can be a bit puzzling at start, don't hesitate to ask some
help on #guix channel.
> - I don't understand why there are ^L separating services in the scheme
> files -- is this necessary? A convention? What purpose does it serve?
Yes, see the "Pagination" section in
https://mumble.net/~campbell/scheme/style.txt. You can install
"emacs-page-break-lines" to replace it by cleaner lines.
> Regarding the patch itself:
>
> - i'm not entirely sure the service belongs to services/linux.scm
I think it's fine.
> - there are no automated tests (beyond what I have done by hand
> locally!), and there's no lint, so I don't really feel confident about
> it :) Are there tests for services to alleviate my fears?
It would be nice to implement tests along with the new service
definition. You can have a look to (gnu tests cups) module for
instance. It tests the cups service by spawning a virtual-machine called
a "marionette". You could create a (gnu tests cachefilesd) doing a
similar job.
See "Running the Test Suite" in the info page for more details on how to
run the test suite.
> - I've copied some other service for modprobing the required kernel
> modules before launching the daemon with a one-shot shepherd
> service. Frankly i'm not happy about this solution, it seems to me
> that it unnecessarily pollutes the shepherd configuration; maybe some
> other mechanism (graft?) adjusting the modprobe configuration could be
> better (better still, autoload the file). Any guidance would be nice
> (including, that this solution is sufficient for now :))
The ideal would be that cachefilesd loads the appropriated module. If
this is not possible, we can discuss extending
kernel-module-loader-service-type service. But for now I guess it's ok.
I hope it answers your questions, I'll review the rest of the service
later on.
Thanks,
Mathieu