qemu-devel
[Top][All Lists]
Advanced

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

Re: Making QEMU easier for management tools and applications


From: Markus Armbruster
Subject: Re: Making QEMU easier for management tools and applications
Date: Mon, 03 Feb 2020 07:20:51 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Paolo Bonzini <address@hidden> writes:

> Il dom 2 feb 2020, 10:22 Kevin Wolf <address@hidden> ha scritto:
>
>> Am 31.01.2020 um 13:27 hat Eric Blake geschrieben:
>> > On 1/28/20 6:54 AM, Kevin Wolf wrote:
>> >
>> > > >
>> > > > The arguments as dotted keys:
>> > > >
>> > > >      id=bar,backend.type=file,backend.data.out=/tmp/bar.log
>> > > >
>> > > > Observe there's quite some of nesting.  While that's somewhat
>> cumbersome
>> > > > in JSON, it's a lot worse with dotted keys, because there nesting
>> means
>> > > > repeated key prefixes.  I could give much worse examples, actually.
>> > >
>> > > This is true, but even without the repeated keys (e.g. in a syntax that
>> > > would use brackets), it would still be unnecessarily verbose and
>> > > probably hard to remember:
>> > >
>> > >      id=bar,backend={type=file,data={out=/tmp/bar.log}}
>>
>> [...] I actually think that a syntax like this might make sense for
>> something like qmp-shell. It might even be more convenient on the
>> command line than dotted keys if you get a lot of repetition (despite
>> the required quoting), but it's strictly speaking incompatible because
>> you could use {} in strings today.
>>
>
> If you are willing to feed schema info to the parser, in principle you
> could keep backwards compatibility. There would be limitations such as
> putting the discriminator before the fields, so I am not sure it's a good
> idea.

Problem: the 'any' type, where the schema doesn't provide the necessary
information.

Problem: 'gen': false, where we pass the arguments raw, ignoring the
schema.

If we didn't restrict alternate types so severly, it would also be a
problem.  For instance, with

    { 'alternate': 'Alt',
      'data': { 'one': 'number',
                'two': 'str' } }

we don't know what to do for value "on" branch to take for value 42.
Not a problem because we reject this alternate.  See
tests/qapi-schema/alternate-conflict-*json for more examples.

> Better QOM introspection would be a requirement, too.

I guess this is what you believe is needed to solve these problems.




reply via email to

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