GNU bug report logs - #34863
[WIP] syscalls: Add loop device interface.

Previous Next

Full log

Message #17 received at 34863 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 34863 <at> debbugs.gnu.org
Subject: Re: [bug#34863] [WIP] syscalls: Add loop device interface.
Date: Sat, 16 Mar 2019 12:17:09 +0100

[Message part 1 (text/plain, inline)]

Hi Ludo :)

On Sat, 16 Mar 2019 11:29:17 +0100
Ludovic Courtès <ludo <at> gnu.org> wrote:

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

See "boot multiple Gnu/Linux Distributions from one USB key" on the guix-devel
list.  This would make it possible to loop-mount stuff at boot.

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

Sure.

> > +(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.

Do you mean 

  open-file ... "r+"

?

>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?

I don't know, but guess it's okay for it to be closed again (the
"losetup" process doesn't keep running for long either and the loop device
is fine).

> > +(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.  

What would I be asserting?  I found no function to test whether an
exception was raised or not (or to just assert that no exception was
raised).  So I resorted to that.

>Also, isn’t ‘loop-device’ a
> number?  Then the ‘set-loop-device-*’ calls fail with wrong-type-arg,
> no?

It's actually a port now and the comment in allocate-new-loop-device is
outdated.

[Message part 2 (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.