[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: qmp-shell for GSoC/Outreachy?
From: |
Daniel P . Berrangé |
Subject: |
Re: qmp-shell for GSoC/Outreachy? |
Date: |
Thu, 6 Feb 2020 12:15:28 +0000 |
User-agent: |
Mutt/1.13.3 (2020-01-12) |
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.
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 :|
- Re: Making QEMU easier for management tools and applications, (continued)
- Re: Making QEMU easier for management tools and applications, Andrea Bolognani, 2020/02/03
- Re: Making QEMU easier for management tools and applications, Kevin Wolf, 2020/02/05
- qmp-shell for GSoC/Outreachy? (Was: Re: Making QEMU easier for management tools and applications), John Snow, 2020/02/05
- Re: qmp-shell for GSoC/Outreachy? (Was: Re: Making QEMU easier for management tools and applications), Dr. David Alan Gilbert, 2020/02/05
- Re: qmp-shell for GSoC/Outreachy?, Markus Armbruster, 2020/02/06
- Re: qmp-shell for GSoC/Outreachy?, Daniel P . Berrangé, 2020/02/06
- Re: qmp-shell for GSoC/Outreachy?, Markus Armbruster, 2020/02/06
- Re: qmp-shell for GSoC/Outreachy?,
Daniel P . Berrangé <=
- Re: qmp-shell for GSoC/Outreachy?, Dr. David Alan Gilbert, 2020/02/06
- Re: qmp-shell for GSoC/Outreachy?, John Snow, 2020/02/07
- Re: qmp-shell for GSoC/Outreachy?, Markus Armbruster, 2020/02/08
- Re: qmp-shell for GSoC/Outreachy?, Kevin Wolf, 2020/02/06
- Re: qmp-shell for GSoC/Outreachy?, Dr. David Alan Gilbert, 2020/02/06
- Re: qmp-shell for GSoC/Outreachy?, Kevin Wolf, 2020/02/07
- Re: qmp-shell for GSoC/Outreachy?, John Snow, 2020/02/07
- Re: qmp-shell for GSoC/Outreachy?, Markus Armbruster, 2020/02/08
- Re: qmp-shell for GSoC/Outreachy?, Kevin Wolf, 2020/02/10
- Re: qmp-shell for GSoC/Outreachy?, Kevin Wolf, 2020/02/10