All of
 help / color / mirror / Atom feed
From: Markus Armbruster <>
To: John Snow <>
Cc:,,,, "Niteesh G. S." <>,
	Stefan Hajnoczi <>
Subject: Re: GSoC Intro - TUI interface for QMP
Date: Thu, 10 Jun 2021 09:19:15 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (John Snow's message of "Wed, 9 Jun 2021 13:06:15 -0400")

John Snow <> writes:

> On 6/9/21 7:56 AM, Markus Armbruster wrote:
>>> The client could cache the information. (Against what kind of an
>>> identifier? Can QEMU report some kind of token that uniquely
>>> identifies its binary or uniquely identifies the set of QAPI commands
>>> it supports?)
>> I proposed something like it to permit QMP clients cache
>> query-qmp-schema output.  Libvirt didn't want it, so it never got beyond
>> the idea stage.
> What ideas did you have for a cache key? We don't need to uniquely
> identify every instance or even every binary.
> I suppose we could use an md5/sha1 checksum of the QMP introspection output?

commit 39a181581650f4d50f4445bc6276d9716cece050
Author: Markus Armbruster <>
Date:   Wed Sep 16 13:06:28 2015 +0200

    qapi: New QMP command query-qmp-schema for QMP introspection


    New QMP command query-qmp-schema takes its return value from that
    variable.  Its reply is some 85KiBytes for me right now.

Has since grown to ~160KiB.
    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
      Right now qmp_query_schema() sends the string literal computed by  To compute sub-schema at run time, we'd have to
      duplicate parts of 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.
    Signed-off-by: Markus Armbruster <>
    Reviewed-by: Eric Blake <>

Note this glosses over what exactly is hashed.  Back then, we generated
query-qmp-schema's output as a string, so we would have hashed that.
Today, we generate a QLitObject.  Less trivial to hash.  Quite feasible
all the same.

NB: Commit messages are love letters to your future self :)


  reply	other threads:[~2021-06-10  7:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2021-05-21 19:02 ` Fwd: GSoC Intro - TUI interface for QMP Niteesh G. S.
2021-05-24 13:32   ` Stefan Hajnoczi
2021-05-24 17:34     ` John Snow
2021-06-02 11:08       ` Bruno Piazera Larsen
2021-06-11 14:06       ` Vladimir Sementsov-Ogievskiy via
2021-05-26 15:35     ` Fwd: " Niteesh G. S.
2021-06-01 23:47       ` John Snow
2021-06-08 15:01         ` Markus Armbruster
2021-06-08 15:49           ` John Snow
2021-06-09 11:56             ` Markus Armbruster
2021-06-09 17:06               ` John Snow
2021-06-10  7:19                 ` Markus Armbruster [this message]
2021-06-09 12:07             ` Daniel P. Berrangé
2021-06-10 14:35               ` John Snow
2021-06-09 12:03           ` Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.