Re: qmp-shell for GSoC/Outreachy?

[Markus Armbruster <armbru@redhat.com>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Thu, Feb 06, 2020 at 10:40:37AM +0100, Markus Armbruster wrote:
>> > If the user screwsup, it should give an error that prompts the user
>> > to the parameter they got wrong.
>> >
>> > Output from commands should normally be pretty formatted (with an option
>> > to display raw json for those needing it).
>> >   e.g. that 'query-version' should give either just the package
>> >   version (as info version currently does) or:
>> >       4.2.50  Package: v4.2.0-1188-gd95a3885a9
>> >
>> > We shouldn't lose any HMP commands that some people find useful
>> >   Ditching HMP isn't an option until we've got almost all of it
>> >   covered.
>> 
>> In particular, we currently use HMP for debugging and monitoring
>> purposes, where we don't need or want QMP's rigor, neither its rigorous
>> interface stability, nor its structured I/O.  We want the "whipuptitude"
>> we get from monitor_printf().  This is actually a point David has made
>> several times.
>
> I'd like to argue that this decision to keep these debugging/monitoring
> things in HMP only was a mistake, because it ensures that QEMU internals
> need to keep HMP related code forever.
>
> What we actually need is a part of QMP that does not have the long term
> stability requirement, nor need for fully structured data. In fact this
> pretty much already exists - we have declared the 'x-' prefix as a way
> to model QMP commands which are experimental / suboptimal / subject
> to change.
>
> I suggest that every HMP command which does not have a QMP equivalent
> should be turned into a QMP command with an "x-" prefix, with no
> extra modelling applied

Makes sense (see my point about "allowing some [whipuptitude] in QMP"),
except I disagree with your example:

> Take "info block"
>
> (hmp) info block
> ide1-cd0: [not inserted]
>     Attached to:      /machine/unattached/device[23]
>     Removable device: not locked, tray closed
>
> floppy0: [not inserted]
>     Attached to:      /machine/unattached/device[16]
>     Removable device: not locked, tray closed
>
> sd0: [not inserted]
>     Removable device: not locked, tray closed
>
>
> I suggest we support it as "x-query-block"
>
> (qmp) x-query-block
> {
>     "return": {
>         "info": "ide1-cd0: [not inserted]
>     Attached to:      /machine/unattached/device[23]
>     Removable device: not locked, tray closed
>
> floppy0: [not inserted]
>     Attached to:      /machine/unattached/device[16]
>     Removable device: not locked, tray closed
>
> sd0: [not inserted]
>     Removable device: not locked, tray closed"
>     }
> }

This commmand does have a QMP equivalent: query-block.

Hmm, no more.  It actually wraps around both query-block and
query-named-block-nodes now.  I think that makes it an example of "go
beyond 1:1".

A better example for "allowing whipuptitude" would be "info registers".

> Functionally we in fact already support pretty much exactly
> that via the "human-monitor-command"  QMP command.
>
> The difference is that with the latter, we will still have to
> keep around the internal dispatching machinery for HMP inside
> QEMU forever. If we transplant all remaining HMP commands with
> an "x-" prefix, we open up the possibility of completely
> separating HMP out and having QEMU work exclusively with QMP
> internally.
>
> This is complementary to an improved qmp-shell client.

Yes.