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

Previous Next

Package: guix-patches;

Reported by: Danny Milosavljevic <dannym <at> scratchpost.org>

Date: Thu, 14 Mar 2019 22:09:01 UTC

Severity: normal

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

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

Danny Milosavljevic <dannym <at> scratchpost.org> skribis:

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

Oh OK (too much mail!).

>> > +      (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+"
>
> ?

Exactly.

>>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).

It’d be good to double-check.  :-)

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

Tests always need to be enclosed in a ‘test-XYZ’ form.  Otherwise it’s
code that’s evaluated as the top level and that’s not listed in the test
log.

So in this case, to check for a 'system-error exception, you could do, say:

  (test-equal "foo"
    ENOENT
    (catch 'system-error
      (lambda () … #f)
      (lambda args
        (system-error-errno args))))

There are examples of that in ‘tests/syscalls.scm’.

HTH!

Ludo’.




This bug report was last modified 74 days ago.

Previous Next


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