Re: [Xen-devel] [PATCH v2 3/5] libxl: xsrestrict QEMU

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 8 Jun 2015, Ian Jackson wrote:
> Stefano Stabellini writes ("[PATCH v2 3/5] libxl: xsrestrict QEMU"):
> > Check whether QEMU supports the xsrestrict option, by parsing its --help
> > output. Store the result on xenstore for future reference on a per QEMU
> > binary basis, so that device_model_override still works fine with it.
> ...
> > +    pid = fork();
> > +    if (pid < 0)
> > +        return ERROR_FAIL;
> 
> Sadly, direct use of fork is forbidden.  See the doc comment for
> libxl__ev_child_fork.
> 
> I hereby volunteer to fix this.

Thanks!!


> But we should probably wait for this
> series to settle down a bit first, as what you have done is suitable
> for testing with xl, at least.
>
> For now, please add a note to the commit message subject ("WIP" or
> "RFC" or something).

Sure, makes sense.


> And, I spotted this:
> 
> > +    /* father parses the output */
> 
> Normally we use "parent" rather than imputing gender to processes...

Good point

 
> > +    s = libxl__strdup(gc, dm);
> > +    libxl__replace_chr(gc, s, '/', '_');
> > +    s = libxl__sprintf(gc, "libxl/%s/%s", s, opt);
> > +    buf = libxl__xs_read(gc, XBT_NULL, s);
> > +    if (buf != NULL)
> > +        return !strcmp(buf, "1");
> 
> This cacheing mechanism is pretty nasty.  Wouldn't it be better to
> save the qemu help output in a disk file, or something ?

We could, but we would still have the same issue of having to store the
output of --help for each different qemu binary on different paths,
which I think is the nasty party.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel