[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.
- Re: Making QEMU easier for management tools and applications, Kevin Wolf, 2020/02/02
- Re: Making QEMU easier for management tools and applications, Andrea Bolognani, 2020/02/03
- Re: Making QEMU easier for management tools and applications, Kevin Wolf, 2020/02/05
- qmp-shell for GSoC/Outreachy? (Was: Re: Making QEMU easier for management tools and applications), John Snow, 2020/02/05
- Re: qmp-shell for GSoC/Outreachy? (Was: Re: Making QEMU easier for management tools and applications), Dr. David Alan Gilbert, 2020/02/05
- Re: qmp-shell for GSoC/Outreachy?, Markus Armbruster, 2020/02/06
- Re: qmp-shell for GSoC/Outreachy?, Daniel P . Berrangé, 2020/02/06
- Re: qmp-shell for GSoC/Outreachy?, Markus Armbruster, 2020/02/06
- Re: qmp-shell for GSoC/Outreachy?, Daniel P . Berrangé, 2020/02/06