unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Danny Milosavljevic <dannym@scratchpost.org>
Cc: 34863@debbugs.gnu.org
Subject: [bug#34863] [WIP] syscalls: Add loop device interface.
Date: Sat, 16 Mar 2019 11:29:17 +0100	[thread overview]
Message-ID: <87k1gzyuwy.fsf@gnu.org> (raw)
In-Reply-To: <20190314220823.30769-1-dannym@scratchpost.org> (Danny Milosavljevic's message of "Thu, 14 Mar 2019 23:08:23 +0100")

Hallo!

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> * guix/build/syscalls.scm (%ioctl-unsigned-long): New procedure.
> (LOOP_CTL_GET_FREE): New macro.
> (LOOP_SET_FD): New macro.
> (LOOP_SET_STATUS64): New macro.
> (LOOP_GET_STATUS64): New macro.
> (lo-flags): New bits.
> (lo-flags->symbols): New procedure.
> (LO_NAME_SIZE): New variable.
> (LO_KEY_SIZE): New variable.
> (%struct-loop-info64): New C structure.
> (allocate-new-loop-device): New procedure.
> (set-loop-device-backing-file): New procedure.
> (get-loop-device-status): New procedure.
> * tests/syscalls.scm: Add test.

What will be the use for this?  I prefer to make sure we only add code
that is actually going to be used.  :-)

> +(define-c-struct %struct-loop-info64
> +  sizeof-loop-info64
> +  (lambda (lo-device lo-inode lo-rdevice lo-offset lo-sizelimit lo-number
> +           lo-encrypt-type lo-encrypt-key-size lo-flags lo-file-name
> +           lo-crypt-name lo-encrypt-key lo-init)
> +    `((lo-device . ,lo-device)
> +      (lo-inode . ,lo-inode)

Like I wrote, a record may be more appropriate than an alist here.
Also, no need to repeat ‘lo-’ in the parameter names.

> +(define (allocate-new-loop-device control-file)
> +  "Allocates a new loop device and returns an FD for it.
> +CONTROL-FILE should be an open file \"/dev/loop-control\".

Nitpick: s/an FD/a file descriptor/
s/an open file/an open port for/

> +      (open-io-file (string-append "/dev/loop" (number->string ret))))

I didn’t know about ‘open-io-file’ and indeed, it’s undocumented.  So
I’d suggest using ‘open-file’ instead to be on the safe side.

> +(define (set-loop-device-backing-file loop-file backing-file)
> +  "Sets up the loop device LOOP-FILE for BACKING-FILE."

Maybe the docstring should be: “Set BACKING-FILE, a port, as the backing
file of LOOP-FILE, an open port to a loopback device.”?

> +  (let-values (((ret err)
> +                (%ioctl-unsigned-long (fileno loop-file) LOOP_SET_FD
> +                                      (fileno backing-file))))

Note that BACKING-FILE, the port, can be closed when it’s GC’d, which as
a side effect would close its associated file descriptor.  Is this OK or
does the FD have to remain open for the lifetime of the loopback device?

In the latter case you’d have to use ‘port->fdes’ instead of ‘fileno’ to
increase the “revealed count” of the port.

> +(define (get-loop-device-status loop-file)

Please add a docstring.  Also I’d remove ‘get-’.

> +(define (set-loop-device-status loop-file status)

Docstring!  :-)

> --- a/tests/syscalls.scm
> +++ b/tests/syscalls.scm
> @@ -564,6 +564,10 @@
>    (let ((result (call-with-input-file "/var/run/utmpx" read-utmpx)))
>      (or (utmpx? result) (eof-object? result))))
>  
> +(let ((loop-device (allocate-new-loop-device (open-io-file "/dev/loop-control"))))
> +  (set-loop-device-backing-file loop-device (open-input-file "tests/syscalls.scm"))
> +  (set-loop-device-status loop-device (get-loop-device-status loop-device)))

You’re missing a ‘test-assert’ or similar.  Also, isn’t ‘loop-device’ a
number?  Then the ‘set-loop-device-*’ calls fail with wrong-type-arg,
no?

Thank you!

Ludo’.

  parent reply	other threads:[~2019-03-16 10:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-14 22:08 [bug#34863] [WIP] syscalls: Add loop device interface Danny Milosavljevic
2019-03-15 16:13 ` Danny Milosavljevic
2019-03-16 10:18   ` Ludovic Courtès
2019-03-16 10:29 ` Ludovic Courtès [this message]
2019-03-16 11:17   ` Danny Milosavljevic
2019-03-18  8:42     ` Ludovic Courtès
2019-04-10 14:56       ` Ludovic Courtès
2019-05-21 14:51       ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k1gzyuwy.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=34863@debbugs.gnu.org \
    --cc=dannym@scratchpost.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).