Re: [libvirt] [Qemu-devel] [RFC PATCH 1/4] qemu-options: Add -filefd command line option

On Tue, May 22, 2012 at 2:38 PM, Kevin Wolf <kwolf(a)redhat.com&gt; wrote: > Am 22.05.2012 15:25, schrieb Corey Bryant: >> >> >> On 05/21/2012 05:40 PM, Eric Blake wrote: >>> On 05/21/2012 02:19 PM, Corey Bryant wrote: >>>> This patch provides support for the -filefd command line option. >>>> This option will allow passing of a filename and its corresponding >>>> file descriptor to QEMU at exec time. >>>> >>>> Signed-off-by: Corey Bryant&lt;coreyb(a)linux.vnet.ibm.com&gt; >>> >>>> +DEF("filefd", HAS_ARG, QEMU_OPTION_filefd, >>>> + "-filefd file=<filename>,fd=<fd>\n" >>> >>> I take it that if filename contains ',', then we have to escape it on >>> the command line? Is it worth passing fd first and file second by >>> default, as a possible way to avoid the need for escaping, or does the >>> option parser not care about ordering? >>> >> >> That's a good question. The options can be ordered either way so I >> don't think we'll force fd to be specified first. I imagine this should >> behave no differently than "-drive file=xyz,if=none,...". I ran a quick >> test using -drive with a filename that had a comma, and (escaped or not) >> it failed on the option parsing. So it looks like if you have a path >> with a comma you're not going to have any luck. > > I think you can escape it, you'd have to use a double comma. But I'd > rather not introduce more of this. It's another good reason for using > /dev/fd/... instead of a translation table. I'm not sure how this solves backing file descriptor passing? How will QEMU know to use /dev/fd/10 for a backing file that is referenced from /dev/fd/9 as "backing.img"? (There was discussion about rewriting backing filenames but I think that solution is risky and we should avoid it.)