Re: qmp-shell for GSoC/Outreachy?

[Markus Armbruster <armbru@redhat.com>]

John Snow <jsnow@redhat.com> writes:

> A note:
>
> qmp-shell could offer some sugared versions of things like "query-block"
> that do some work understanding the reply from QEMU and printing it in a
> nice human format.

This is exactly how HMP commands should work.

By moving them to qmp-shell, we get to code them in qmp-shell's language
(Python, I guess) rather than C.

I think we need to decide what qmp-shell's mission should be: is it a
better socat for the QMP monitor, or a replacement for the traditional
HMP monitor?

You may answer "both".  It'll complicate things, though.  More on that
below.

> This is generally what I have in mind for things when it's possible: use
> "real" QMP interfaces to do the query, and then use qmp-shell code to
> display "pretty" results.
>
> e.g.
>
>>> query-block
>
> might execute the raw QMP command and give you back the giant textwall
> of gibberish, but perhaps:
>
>>> ?info block
>
> would execute query-block behind the scenes, digest the results, and
> pretty-print some results.
>
> These shell-local commands, denoted by the "?" prefix, could be
> user-extensible python extensions that simply react to incoming data,
> optionally perform extra work, and display results.

As long as we develop qmp-shell and QMP together, we don't *have* to
separate name spaces.  It could simply be "info block".

However, consider chardev-add.  Example from char.json:

    -> { "execute" : "chardev-add",
         "arguments" : { "id" : "baz",
                         "backend" : { "type" : "pty", "data" : {} } } }
    <- { "return": { "pty" : "/dev/pty/42" } }

Here's the HMP equivalent:

    (qemu) chardev-add pty,id=baz
    char device redirected to /dev/pts/16 (label baz)

With your proposed "?" prefix, the straightforward way to run
chardev-add gives your the (thankfully non-giant) textwall of gibberish.
If you stick in a "?" and change the "-" to "_", you get the
pretty-printed version.  Not exactly the kind of UX we strive for, I'm
afraid, even if we fix the '-' vs. '_' nonsense.

If qmp-shell aims to be a better socat for the QMP monitor, then "?info
block" is out of scope, and so is pretty-printed chardev-add.

If qmp-shell aims to replace HMP, then query-block is out of scope, and
so is JSON-printing chardev-add.  Also, "qmp-shell" is a misnomer.

If qmp-shell aims to do both, we need to try harder :)

Kevin mentioned another way to provide HMP-like functionality in
qmp-shell: "have a QMP mode and an HMP mode and the user can switch
between these modes."

> Otherwise, for commands where this is too laborious, too intensive, or
> just not worth it -- but we cannot be rid of them -- I like Dan's idea
> of just offering e.g.
>
> 'x-debug-foo' and returning big text blobs, so we don't have to waste
> any brain-calories on devising a properly structured response.

To actually replace HMP, we'll want such commands.

> Actually, we can even use the featureflags to tag such commands as e.g.
> "human-ui-only" and could conditionally compile them out for enterprise
> deployments where poor behavior WRT synchronicity is a security liability.

Everybody knows enterprise deployments always work, and always perform
perfectly.  Commands for debugging and monitoring them are quite
superfluous ;-P