[Top][All Lists]

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

Re: [Qemu-devel] [RFC PATCH 00/11] qapi changes in preparation for block

From: Kevin Wolf
Subject: Re: [Qemu-devel] [RFC PATCH 00/11] qapi changes in preparation for blockdev-add
Date: Fri, 12 Jul 2013 12:53:13 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 12.07.2013 um 11:55 hat Laszlo Ersek geschrieben:
> On 07/09/13 11:53, Kevin Wolf wrote:
> > The goal of this series is to make QAPI ready to handle mostly unions in a 
> > less
> > verbose way so that a future -blockdev command line option can be a
> > direct mapping of the structure used by a blockdev-add QMP command. This
> > series implements everything that I think is needed for this on the QAPI
> > side. The block layer side is still lacking, but good enough that I
> > could actually add a block device using the new command; the problem is
> > here mostly that many -drive options aren't supported yet.
> Apologies for arriving late to the party...
> Do you think this could be handled by OptsVisitor? See the message part
> of commit eb7ee2cb. (Directly following commits in the history
> demonstrate use of the visitor.)
> Using OptsVisitor, you'd receive a flat structure, specific to the
> discriminator value selected. You'd have to transform that flat struct
> into the qapi object tree that blockdev-add already takes; the benefit
> is that the usual qemu-opt fishing and basic syntax validation would be
> covered.
> Your requirements are probably more complex than what OptsVisitor can
> handle, but I'd like you to read the commit message and say, "yes, this
> is insufficient for me". :)

I think OptsVisitor is about something else than this series. Here I'm
really adding a QMP part, while -drive is an existing command line
option that isn't changed and -blockdev isn't added yet.

But anyway, thanks for mentioning it, I wasn't aware that it exists. It
certainly doesn't replace this series, but it might prove useful in the
few lines that currently convert the QAPI struct to the QemuOpts that
drive_init() currently takes. I'm doing a detour through QDict to create
the QemuOpts currently and this may be something I can save (or maybe
not because I need to flatten the structure by turning e.g. a field
'filename' in the nested struct 'backing' into 'backing.filename')

When we later make the command line option use the QMP command, like it
should, instead of the other way round, OptsVisitor might be the way to
parse the command line. I'll keep it at the back of my mind, and if
necessary I can try to extend it when I get to this.


reply via email to

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