guix-patches
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]