Re: [Qemu-devel] [PATCH v13 6/6] qom: support arbitrary non-scalar properties with -object

[Daniel P. Berrange]

On Mon, Sep 19, 2016 at 02:19:19PM +0200, Paolo Bonzini wrote:
> 
> 
> On 19/09/2016 14:12, Daniel P. Berrange wrote:
> > On Mon, Sep 19, 2016 at 12:58:30PM +0100, Daniel P. Berrange 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.
> > 
> > Urgh, I've just discovered that this is not in fact true.
> > 
> > The 'memory-backend' object type uses uint16List which
> > has the hacky list syntax
> > 
> >   -object memory-backend-ram,\
> >           id=ram-node2,size=24578621440,policy=bind,\
> >           host-nodes=1-2,host-nodes=5,host-nodes=7,
> > 
> > So I'll need to figure out a way to preserve this syntax...
> 
> Is there a usecase for qdict_crumple without the following
> de-stringification pass?  If not, qdict_crumple could use a
> StringInputVisitor on the values directly.

I'm not sure I understand how that would help and in any case, the
string-input-visitor itself is incapable of dealing with compound
properties. It too could/should be ultimately replaced by the
qobject-input-visitor combined with a pre-processing step to
turn the input string into a qdict.

The problem I'm facing with the above scenario though occurs
before we get anywhere near the visitors, or the crumple step.

When qemu_opts_to_qdict() turns QemuOpts into QDict, it looses
repeated options. So given a command line


   -object memory-backend-ram,\
           id=ram-node2,size=24578621440,policy=bind,\
           host-nodes=1-2,host-nodes=5,host-nodes=7,

we're getting an initial QDict containing

    type=memory-backend-ram
    id=ram-node2
    size=24578621440
    policy=bind
    host-nodes=7

What I need to do is make qemu_opts_to_qdict more intelligent
so that if it sees repeated strings, it inserts them into the
qdict using list index style. eg, the QemuOpts -> QDict
conversion should have at minimum given us

    type=memory-backend-ram
    id=ram-node2
    size=24578621440
    policy=bind
    host-nodes.0=1-2
    host-nodes.1=5
    host-nodes.2=7

although even then there's some magic in the range value seen there. I'm
unclear on whether we should try to deal with the range "1-2" in the
qemu_opts_to_qdict() method, the qdict_crumple() method or the qobject
input visitor code for parsing ints.

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 :|