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,\
>>> 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
> 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.
> 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
> 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.