qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kevin Wolf
Subject: Re: [Qemu-devel] [RFC PATCH 1/4] qemu-options: Add -filefd command line option
Date: Tue, 22 May 2012 16:39:49 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

Am 22.05.2012 16:26, schrieb Stefan Hajnoczi:
> On Tue, May 22, 2012 at 2:38 PM, Kevin Wolf <address@hidden> 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<address@hidden>
>>>>
>>>>> +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.)

By getting an override for the backing file. I'm making something up
now, but it could look like this:

{ "execute": "blockdev-add",
  "arguments": {
    "name": "my_backing_file",
    "format": "raw",
    "filename": "/dev/fd/10"
  }
}

{ "execute": "blockdev-add",
  "arguments": {
    "name": "my_disk",
    "format": "qcow2",
    "filename": "/dev/fd/9",
    "backing_file": "my_backing_file"
    /* backing_fmt is not overridden and read from qcow2 */
  }
}

If you absolutely must have it today (this is not meant to be used, but
to push -blockdev development ;-)), it looks like this:

(qemu) drive_add 0 file=/dev/fd/10,format=raw,if=none,id=my_disk

{ "execute" : "blockdev-snapshot-sync",
  "arguments" : {
     "device": "my_disk",
     "snapshot-file": "/dev/fd/9",
     "format": "qcow2",
     "mode": "existing"
  }
}

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]