| Message ID | 1337631598-30639-2-git-send-email-coreyb@linux.vnet.ibm.com |
|---|---|
| State | New |
| Headers | show |
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 <coreyb@linux.vnet.ibm.com> > +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?
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<coreyb@linux.vnet.ibm.com> > >> +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.
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<coreyb@linux.vnet.ibm.com> >> >>> +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. Kevin
On Tue, May 22, 2012 at 2:38 PM, Kevin Wolf <kwolf@redhat.com> 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<coreyb@linux.vnet.ibm.com> >>> >>>> +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.) Stefan
Am 22.05.2012 16:26, schrieb Stefan Hajnoczi: > On Tue, May 22, 2012 at 2:38 PM, Kevin Wolf <kwolf@redhat.com> 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<coreyb@linux.vnet.ibm.com> >>>> >>>>> +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
diff --git a/qemu-config.c b/qemu-config.c index be84a03..64afac6 100644 --- a/qemu-config.c +++ b/qemu-config.c @@ -613,6 +613,22 @@ QemuOptsList qemu_boot_opts = { }, }; +QemuOptsList qemu_filefd_opts = { + .name = "filefd", + .head = QTAILQ_HEAD_INITIALIZER(qemu_filefd_opts.head), + .desc = { + { + .name = "file", + .type = QEMU_OPT_STRING, + }, { + .name = "fd", + .type = QEMU_OPT_NUMBER, + }, + { /*End of list */ } + }, +}; + + static QemuOptsList *vm_config_groups[32] = { &qemu_drive_opts, &qemu_chardev_opts, @@ -628,6 +644,7 @@ static QemuOptsList *vm_config_groups[32] = { &qemu_machine_opts, &qemu_boot_opts, &qemu_iscsi_opts, + &qemu_filefd_opts, NULL, }; diff --git a/qemu-config.h b/qemu-config.h index 6d7365d..6be54f1 100644 --- a/qemu-config.h +++ b/qemu-config.h @@ -4,6 +4,7 @@ extern QemuOptsList qemu_fsdev_opts; extern QemuOptsList qemu_virtfs_opts; extern QemuOptsList qemu_spice_opts; +extern QemuOptsList qemu_filefd_opts; QemuOptsList *qemu_find_opts(const char *group); void qemu_add_opts(QemuOptsList *list); diff --git a/qemu-options.hx b/qemu-options.hx index 8b66264..5f6782c 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -2743,6 +2743,23 @@ DEF("qtest-log", HAS_ARG, QEMU_OPTION_qtest_log, "-qtest-log LOG specify tracing options\n", QEMU_ARCH_ALL) +DEF("filefd", HAS_ARG, QEMU_OPTION_filefd, + "-filefd file=<filename>,fd=<fd>\n" + " passes a filename and its corresponding file descriptor\n", + QEMU_ARCH_ALL) +STEXI +@item -filefd file=@var{filename},fd=@var{fd} +@findex -filefd +This is used when a management application opens a file on behalf of QEMU. +Instead of performing an open, QEMU will use the fd passed on this option. +@table @option +@item file=@var{filename} +The name of the file. +@item fd=@var{fd} +The file descriptor that corresponds to @var{filename}. +@end table +ETEXI + HXCOMM This is the last statement. Insert new options before this line! STEXI @end table
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 <coreyb@linux.vnet.ibm.com> --- qemu-config.c | 17 +++++++++++++++++ qemu-config.h | 1 + qemu-options.hx | 17 +++++++++++++++++ 3 files changed, 35 insertions(+), 0 deletions(-)