qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH RFC v5 30/32] qapi: New QMP command query-qmp-sc


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH RFC v5 30/32] qapi: New QMP command query-qmp-schema for QMP introspection
Date: Fri, 11 Sep 2015 15:30:55 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

"Daniel P. Berrange" <address@hidden> writes:

> On Fri, Sep 11, 2015 at 09:02:15AM +0200, Markus Armbruster wrote:
>> Michael Roth <address@hidden> writes:
>> 
>> > Quoting Markus Armbruster (2015-09-07 05:16:41)
>> >> A new test-qmp-input-visitor test case feeds its result for both
>> >> tests/qapi-schema/qapi-schema-test.json and qapi-schema.json to a
>> >> QmpInputVisitor to verify it actually conforms to the schema.
>> >> 
>> >> New QMP command query-qmp-schema takes its return value from that
>> >> variable.  Its reply is some 85KiBytes for me right now.
>> >> 
>> >> If this turns out to be too much, we have a couple of options:
>> >> 
>> >> * We can use shorter names in the JSON.  Not the QMP style.
>> >> 
>> >> * Optionally return the sub-schema for commands and events given as
>> >>   arguments.
>> >> 
>> >>   Right now qmp_query_schema() sends the string literal computed by
>> >>   qmp-introspect.py.  To compute sub-schema at run time, we'd have to
>> >>   duplicate parts of qapi-introspect.py in C.  Unattractive.
>> >> 
>> >> * Let clients cache the output of query-qmp-schema.
>> >> 
>> >>   It changes only on QEMU upgrades, i.e. rarely.  Provide a command
>> >>   query-qmp-schema-hash.  Clients can have a cache indexed by hash,
>> >>   and re-query the schema only when they don't have it cached.  Even
>> >>   simpler: put the hash in the QMP greeting.
>> >
>> > Would probably be easier for management to build up their own structure
>> > for querying caps, so I think a computed hash seems best. But I don't
>> > think either is something that couldn't be added later if need be.
>> 
>> I also think a hash is the way to go, and I'd like to provide one early,
>> but I don't want to delay this series for it.
>
> FWIW, libvirt already caches the results of its query of QEMU and will
> only re-query QEMU if the timestamp of the QEMU binary on disk has
> changed, or if libvirt itself has changed.  Also when querying the QEMU
> capabilities there are quite a few commands we run, we want to cache
> the full set, not just query-qmp-schema, so we can avoid launching QEMU
> at all. o at least from Libvirt's POV, I don't think we have a need for
> a hash of query-qmp-schema.

Noted.



reply via email to

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