Subject: Re: [bug#34638] [PATCH 2/4] linux-container: Add 'start-child-in-container'.

From: Christopher Baines <[email-masked]>
Date: Fri, 19 Apr 2019 15:16:40 +0100

Ludovic Courtès <[email-masked]> writes:

> Hello!
>
> Christopher Baines <[email-masked]> skribis:
>
>> This new procedure is similar to open-pipe* in (ice-9 popen), but using
>> run-container from (gnu build linux-container).
>>
>> * gnu/build/linux-container.scm (start-child-in-container): New procedure.
>
> [...]
>
>  +(define* (start-child-in-container command
>> +                                   #:key read? write?
>> +                                   (root 'temporary)
>> +                                   (mounts '())
>> +                                   (namespaces %namespaces)
>> +                                   (host-uids 1)
>> +                                   (extra-environment-variables '()))
>
> We could even call that ‘open-pipe/container’, for clarity.

I've made some changes (see below) that move this a little further away
from open-pipe in terms of behaviour now.

>> +  (define (with-root-directory f)
>> +    (if (eq? root 'temporary)
>> +        (call-with-temporary-directory f)
>> +        (f root)))
>> +
>> +  ;; (ice-9 popen) internals
>> +  (define make-rw-port (@@ (ice-9 popen) make-rw-port))
>> +  (define pipe-guardian (@@ (ice-9 popen) pipe-guardian))
>> +  (define make-pipe-info (@@ (ice-9 popen) make-pipe-info))
>
> So this is the funky part.  ;-)
>
> What if we did something like:
>
>   (call-with-container mounts
>     (lambda ()
>       ;; Somehow act as a proxy between the output process
>       ;; and the one spawned by ‘open-pipe*’.
>       (open-pipe* …)))
>
> ?  Would that work?
>
> That’s create an extra process, but if it works, it’s probably safer and
> a lesser maintenance burden.
>
> Now, I think that Guile should expose some of the popen internals
> somehow so we can do things like you did, but that’s another story.

I'm hesitant to try that, as the additional process in the middle seems
a bit awkward to me.

I've made another pass over the code, removed all the uses of (ice-9
popen) internals, and sent another set of patches. For the make-rw-port
function, I just copied that over. The pipe-guardian isn't being used
now, and instead of returning a <pipe-info> record, the port and pid are
returned instead. This works with the inferior use case, as the close
function provided to port->inferior does the right thing, closing the
port and then waiting for the child process to exit, just like popen.

I'm still more interested in getting something working than it being
perfect in any particular way, but let me know what you think.

Thanks,

Chris