On 19/09/2016 14:29, Daniel P. Berrange wrote: > 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. Ouch, I thought the problem was only with "1-2", not with the repeated host-nodes. Wow, that does really work?!? What might work is if you convert the repeated options to "host-nodes=1-2,5,7". Then StringInputVisitor is able to parse that (but OptsVisitor isn't). I'm not sure if there are other uses of repeated options. Probably not based on a limited inspection of callers of qemu_opt_foreach. Paolo > 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 >
