From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWqGF-0008RM-Vv for qemu-devel@nongnu.org; Tue, 22 May 2012 10:41:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWqFl-0001HP-Ob for qemu-devel@nongnu.org; Tue, 22 May 2012 10:40:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25900) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWqFl-0001FP-HP for qemu-devel@nongnu.org; Tue, 22 May 2012 10:40:01 -0400 Message-ID: <4FBBA535.4010704@redhat.com> Date: Tue, 22 May 2012 16:39:49 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1337631598-30639-1-git-send-email-coreyb@linux.vnet.ibm.com> <1337631598-30639-2-git-send-email-coreyb@linux.vnet.ibm.com> <4FBAB641.20109@redhat.com> <4FBB93BC.9080901@linux.vnet.ibm.com> <4FBB96CA.3010500@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 1/4] qemu-options: Add -filefd command line option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: aliguori@us.ibm.com, stefanha@linux.vnet.ibm.com, libvir-list@redhat.com, Corey Bryant , qemu-devel@nongnu.org, Eric Blake Am 22.05.2012 16:26, schrieb Stefan Hajnoczi: > On Tue, May 22, 2012 at 2:38 PM, Kevin Wolf 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 >>>> >>>>> +DEF("filefd", HAS_ARG, QEMU_OPTION_filefd, >>>>> + "-filefd file=,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