qemu-devel
[Top][All Lists]
Advanced

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

Re: GSoC Intro - TUI interface for QMP


From: John Snow
Subject: Re: GSoC Intro - TUI interface for QMP
Date: Tue, 8 Jun 2021 11:49:41 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1

On 6/8/21 11:01 AM, Markus Armbruster wrote:
John Snow <jsnow@redhat.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
itself.

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.



ACK, understood.

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.

--js




reply via email to

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