[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 3/5] libxl: xsrestrict QEMU
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |