* Daniel P. Berrangé (berra...@redhat.com) wrote: > On Thu, Feb 06, 2020 at 01:11:58PM +0100, Markus Armbruster wrote: > > Daniel P. Berrangé <berra...@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. > > 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 / dgilb...@redhat.com / Manchester, UK