On 19/10/21 22:29, Mark Kanda wrote:
+#
+# @filter: KVM stat name (optional)
Nitpicking on the name, "filter" makes me think that some kind of
globbing is supported. So I would just call it "name".
Also nitpicking on the name, let's drop "kvm" from everything. In the
future other subsystems could expose statistics, both in the kernel and
in QEMU (e.g. vhost or TAP; even query-blockstats could be integrated).
Finally, I think we should decouple the description of the stats and the
description of the sources of said stats. For example:
name type
---- ----
vm kvm-vm
vcpu_0 kvm-vcpu
...
This way the caller knows that the "vcpu_*" stats follow the same
schema. That would be:
# e.g. name: 'vm', 'type: 'kvm-vm'
# or name: 'vcpu_0', 'type: 'kvm-vcpu'
{ 'struct': 'StatsInstance',
'data': {'name': 'str', 'type': 'str'}}
{ 'struct': 'StatsSchema',
'data': {'type': 'str', 'stats': [ 'KvmStatSchema' ] } }
{ 'struct': 'StatsValues',
'data': {'name': 'str', type': 'str', 'values': [ 'int64' ] } }
{ 'command': 'query-stats-instances',
'returns': [ 'StatsInstances' ] }
{ 'command': 'query-stats-schemas',
'data': { '*type': 'str' },
'returns': [ 'StatsSchema' ] }
{ 'command': 'query-stats',
'data': { '*name': 'str', '*type': 'str' },
'returns': [ 'StatsValues' ] }
This should be enough to make the API more future proof.
Paolo
