Re: qmp-shell for GSoC/Outreachy?

[Dr. David Alan Gilbert]

* Daniel P. Berrangé (address@hidden) wrote:
> On Thu, Feb 06, 2020 at 01:11:58PM +0100, Markus Armbruster wrote:
> > Daniel P. Berrangé <address@hidden> 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.
> 
> Doh, I should have actually checked before picking a random
> example :-)
> 
> > 
> > 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".
> 
> Yep, that's a classic that would be horribly painful to try to represent
> as a fully structured set of arrays & dicts for all architectures.

'info registers' is a challenge for JSON since it's all 64bit unsigned
int's;  you really want the result to be in hex, and definitely not to
have been randomly sign extended or truncated, or converted to float or
whatever other evils a json processor might do.  So the user wants
a nice consistent format.

'info qtree' and 'info mtree' are other interesting cases that I use
very frequently.

Dave



> 
> Regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK