From: John Snow <firstname.lastname@example.org>
To: Markus Armbruster <email@example.com>
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
email@example.com, "Niteesh G. S." <firstname.lastname@example.org>,
Stefan Hajnoczi <email@example.com>
Subject: Re: GSoC Intro - TUI interface for QMP
Date: Tue, 8 Jun 2021 11:49:41 -0400 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 6/8/21 11:01 AM, Markus Armbruster wrote:
> John Snow <email@example.com> writes:
>> A challenge will be where to pull the help text from. The QEMU server
>> is not capable (today) of sending help information over the QMP socket
>> We will need to implement a QMP command inside of QEMU directly that
>> is capable of delivering this information to the client so that it can
>> render it.
>> Since not all versions of QEMU will have this feature, the qmp-shell
>> will need to be able to gracefully deal with the lack of help text,
>> displaying an error indicating that this version of QEMU does not have
>> help information compiled into it.
> The doc text is bulky: my bld/docs/manual/interop/qemu-qmp-ref.html is
> 1.7 MiB and growing. Less lavish markup results in smaller data. We
> may want to store it compressed, or load it on demand. We might even
> have to make it compile-time optional for some use cases.
raw QAPI directory, including only the json files, is "only" 551.3 kB.
I assume we can compile help text to something json (or json-like) and
then compress it. Perhaps we could compile something like
qapi-help-introspect.json.tgz and load it on-demand from the QEMU binary
when help text is requested.
We could prototype under the experimental QMP command x-help, and limit
it to sending help for just one command at a time to limit data transfer.
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?)
This has the potential to exceed our capacity this summer, but a
prototype experiment might be helpful to inform future work anyway.
next prev parent reply other threads:[~2021-06-08 15:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAN6ztm-J2GoQKkLb=Az0H2Q8UKK4oE3PgXg7g14=T53sQAUyDg@mail.gmail.com>
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 [this message]
2021-06-09 11:56 ` Markus Armbruster
2021-06-09 17:06 ` John Snow
2021-06-10 7:19 ` Markus Armbruster
2021-06-09 12:07 ` Daniel P. Berrangé
2021-06-10 14:35 ` John Snow
2021-06-09 12:03 ` Daniel P. Berrangé
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.