unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Value in adding Shepherd requirements to file-systems entries?
@ 2024-04-23  3:43 Richard Sent
  2024-04-23  4:31 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
  2024-05-02  9:15 ` Ludovic Courtès
  0 siblings, 2 replies; 12+ messages in thread
From: Richard Sent @ 2024-04-23  3:43 UTC (permalink / raw)
  To: guix-devel

Hi Guix!

I wanted to ask the Guix community for their thoughts on improving the
support for adding networked file systems to an operating-system
declaration.

For some context, I started tackling adding CIFS support to file-system
declarations, but I've hit a snag. CIFS is a networked file system, but
Guix mounts all file systems specified in
(operating-system-file-systems) either when booting the system from the
initrd or as shepherd services after boot that depend on
'root-file-system and 'udev.

Either way, these run before any networking service has been
initialized. Ergo, a samba share like //192.168.1.102/share won't be
found. (At least, not on a wireless network. Perhaps the timing is
different for wired ones.)

Obviously, adding shepherd requirements to needed-at-boot? file systems
isn't possible. However, I think it should be possible to add shepherd
services to other file system entries.

(And yet, NFS is allegedly supported, although I can't figure out the
mechanism for that and don't have one set up on my LAN for testing.)

Before hacking away at this myself, I'd like to get other people's
thoughts on the best way to proceed. Do others agree that (file-system)
entries should support networked devices? Should this be transparent
depending on the type, or require explicit configuration?

e.g.

--8<---------------cut here---------------start------------->8---
(file-system
  (device "//192.168.1.102/share")
  (options "guest")
  (mount-point "/mnt/share")
  (type "cifs")
  ;; Should we explicitly require network, or implicitly add it from
  ;; the type? If the latter, what to do about Avahi?
  (requirement 'networking)
  (mount-may-fail? #t)
  (create-mount-point? #t))
--8<---------------cut here---------------end--------------->8---

I could see this being challenging since it's not immediately clear to
me what particular file-system-* service, if any, is provisioning
'file-systems, which other shepherd requirements the user may specify
can depend on. I imagine adding a requirement to the wrong file-system
could easily cause a deadlock.

I know a custom shepherd service could be used to run, say, mount.cifs
from userspace after networking is provisioned, but in my opinion it
would be cleaner to encapsulate within the existing file-system block of
the operating system.

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2024-07-19 18:27 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-23  3:43 Value in adding Shepherd requirements to file-systems entries? Richard Sent
2024-04-23  4:31 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-04-24  0:45   ` Richard Sent
2024-04-26 19:31     ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-04-27  0:16       ` Attila Lendvai
2024-06-07 11:11     ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-06-07 13:52       ` Richard Sent
2024-06-08  1:22         ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-06-08  2:21           ` Richard Sent
2024-07-19 18:26         ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-05-02  9:15 ` Ludovic Courtès
2024-05-02 12:45   ` Richard Sent

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).