Re: qmp-shell for GSoC/Outreachy?

[John Snow <jsnow@redhat.com>]

On 2/6/20 7:11 AM, Markus Armbruster wrote:
> 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.
> 

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 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.

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.

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.

--js