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: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH RFC v5 30/32] qapi: New QMP command query-qmp-schema for QMP introspection
Date: Fri, 11 Sep 2015 09:33:53 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

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.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



reply via email to

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