qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v6 4/7] qom: support arbitrary non-scalar proper


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH v6 4/7] qom: support arbitrary non-scalar properties with -object
Date: Wed, 29 Jun 2016 13:20:20 +0100
User-agent: Mutt/1.6.1 (2016-04-27)

On Tue, Jun 28, 2016 at 06:09:08PM +0200, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Jun 14, 2016 at 6:07 PM, Daniel P. Berrange <address@hidden> wrote:
> > The current -object command line syntax only allows for
> > creation of objects with scalar properties, or a list
> > with a fixed scalar element type. Objects which have
> > properties that are represented as structs in the QAPI
> > schema cannot be created using -object.
> >
> > This is a design limitation of the way the OptsVisitor
> > is written. It simply iterates over the QemuOpts values
> > as a flat list. The support for lists is enabled by
> > allowing the same key to be repeated in the opts string.
> >
> > It is not practical to extend the OptsVisitor to support
> > more complex data structures while also maintaining
> > the existing list handling behaviour that is relied upon
> > by other areas of QEMU.
> >
> > Fortunately there is no existing object that implements
> > the UserCreatable interface that relies on the list
> > handling behaviour, so it is possible to swap out the
> > OptsVisitor for a different visitor implementation, so
> > -object supports non-scalar properties, thus leaving
> > other users of OptsVisitor unaffected.
> >
> > The previously added qdict_crumple() method is able to
> > take a qdict containing a flat set of properties and
> > turn that into a arbitrarily nested set of dicts and
> > lists. By combining qemu_opts_to_qdict and qdict_crumple()
> > together, we can turn the opt string into a data structure
> > that is practically identical to that passed over QMP
> > when defining an object. The only difference is that all
> > the scalar values are represented as strings, rather than
> > strings, ints and bools. This is sufficient to let us
> > replace the OptsVisitor with the QMPInputVisitor for
> > use with -object.
> >
> > Thus -object can now support non-scalar properties,
> > for example the QMP object
> >
> >   {
> >     "execute": "object-add",
> >     "arguments": {
> >       "qom-type": "demo",
> >       "id": "demo0",
> >       "parameters": {
> >         "foo": [
> >           { "bar": "one", "wizz": "1" },
> >           { "bar": "two", "wizz": "2" }
> >         ]
> >       }
> >     }
> >   }
> >
> > Would be creatable via the CLI now using
> >
> >     $QEMU \
> >       -object demo,id=demo0,\
> >               foo.0.bar=one,foo.0.wizz=1,\
> >               foo.1.bar=two,foo.1.wizz=2
> >
> > Notice that this syntax is intentionally compatible
> > with that currently used by block drivers.
> >
> > This is also wired up to work for the 'object_add' command
> > in the HMP monitor with the same syntax.
> >
> >   (hmp) object_add demo,id=demo0,\
> >                    foo.0.bar=one,foo.0.wizz=1,\
> >                    foo.1.bar=two,foo.1.wizz=2
> >
> > NB indentation should not be used with HMP commands, this
> > is just for convenient formatting in this commit message.
> >
> > Signed-off-by: Daniel P. Berrange <address@hidden>
> 
> The patch breaks parsing of size arguments:
> 
> -object memory-backend-file,id=mem,size=512M,mem-path=/tmp: Parameter
> 'size' expects a number
> 
> 
> Looks like the previous patch needs type_size support

Yep, I've modified the previous patch to implement the type_size callback
on the QMP visitor and added a unit test case for this too.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



reply via email to

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