qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v3 1/3] qmp: Support for querying stats


From: Markus Armbruster
Subject: Re: [PATCH v3 1/3] qmp: Support for querying stats
Date: Fri, 11 Feb 2022 14:51:30 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Tue, Feb 01, 2022 at 11:51:26AM +0100, Paolo Bonzini wrote:
>> On 1/31/22 20:43, Mark Kanda wrote:
>> > 
>> > { "execute": "query-stats", "arguments" : { "target": "vm" } }
>> > { "return": {
>> >      "list": [
>> >        { "provider": "kvm",
>> >          "stats": [
>> >            { "name": "max_mmu_page_hash_collisions", "value": 0 },
>> >            { "name": "max_mmu_rmap_size", "value": 0 },
>> >            { "name": "nx_lpage_splits", "value": 131 },
>> >           ...
>> >          ] }
>> >        { "provider": "provider XYZ",
>> >        ...
>> >      ],
>> >      "target": "vm"
>> >    }
>> > }
>> 
>> Perhaps it's better to have a better name than "list" for clarity, like you
>> already did with 'stats':
>> 
>> { 'struct': 'VCPUResultsEntry',
>>   'data': { 'path': 'str',
>>             'providers': [ 'StatsResultsEntry' ] } }
>> 
>> { 'struct': 'VCPUStatsResults',
>>   'data': { 'objects': [ 'VCPUResultsEntry' ] } }
>> 
>> 
>> { 'struct': 'VMStatsResults',
>>   'data': { 'providers' : [ 'StatsResultsEntry' ] } }
>> 
>> Also, here:
>> 
>> > +{ 'alternate': 'StatsValue',
>> > +  'data': { 'scalar': 'uint64',
>> > +            'list': 'StatsValueArray' } }
>> 
>> is it possible to just do
>> 
>> { 'alternate': 'StatsValue',
>>   'data': { 'scalar': 'uint64',
>>             'list': ['uint64'] } }
>
> No, the QAPI generator throws its toys out of the pram.
>
> It claims you can have any set of data types which have a
> distinct representation on the wire, so this is valid from
> that POV.  Something about the parser/code generator can't
> cope with this inline array though - it wants a named type
> which means a built-in scalar, or a compound type, but not
> an array :-(

Array is not implemented, simply because we haven't had a use for it.

Should not make you settle for an inferior schema design!  Implementing
array alternates shouldn't be hard.




reply via email to

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