Re: [Qemu-devel] [PATCH v2] Show values and description when using "qom-list"

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Markus Armbruster (armbru@redhat.com) wrote:
> Markus Armbruster <armbru@redhat.com> writes:
> 
> > Andreas Färber <afaerber@suse.de> writes:
> >
> >> Am 08.06.2018 um 11:41 schrieb Dr. David Alan Gilbert:
> >>> * Andreas Färber (afaerber@suse.de) wrote:
> >>>> Am 01.06.2018 um 17:39 schrieb Ricardo Perez Blanco:
> >>>>> For debugging purposes it is very useful to:
> >>>>>  - See the description of the field. This information is already filled
> >>>>>    in but not shown in "qom-list" command.
> >>>>
> >>>> No objection on this part.
> >>>>
> >>>>>  - Display value of the field.
> >>>>
> >>>> That is by definition the qom-get operation, not qom-list. Just like the
> >>>> ls command does not show file contents, there's cat etc. for that. For
> >>>> debugging purposes we had a qom-tree (?) command that would combine
> >>>> both.
> >>>
> >>> I'm not too bothered about distinguishing between the two commands;
> >>> but it would be nice
> >
> > When an HMP and QMP both have a command with the same name, they should
> > do the same.
> >
> > HMP may add convenience features that aren't wanted in QMP, but I feel
> > extending an operation to list objects to also show their contents goes
> > beyond that.  If we want an HMP command that does both, it should be
> > named differently.  Perhaps that might even be more appropriate for HMP
> > than low-level commands qom-list and qom-get, but I leave that to the
> > HMP maintainer to decide.
> >
> >>>                      - one reason I'm not too bothered is because we've
> >>> failed to get a qom-get in multiple years of trying.
> >
> > We clearly haven't tried hard enough.
> >
> > If we can figure out how to show values in qom-list, surely we can
> > figure out how to show them in qom-get.
> >
> >>>>       There might be unmerged patches on qemu-devel related to display
> >>>> of certain data types.
> >>> 
> >>> Which ones?
> >>
> >> My original qom-info series needed StringOutputVisitor changes for enums
> >> (test case: rtc) that did not get accepted immediately and thus some
> >> part of HMP qom-info/qom-get got stuck due to risking assertions for
> >> qom-info / otherwise; QMP was not affected IIRC.
> >
> > Here's the last try I can find:
> > [PATCH v2] qom: Implement qom-get HMP command
> > Message-Id: <1473157086-12062-1-git-send-email-dgilbert@redhat.com>
> > https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg01041.html
> 
> Stalled on output format and consistency with qom-set.  I wrote back
> then "We can take qom-get as is and improve its output later."  I'd like
> to encourage you to dust it off.  Perfect's the enemy of good.
> 
> Wanted improvements include:
> 
> * Prettier output format.  I'd suggest creating a keyval variant of the
>   output visitor.

I'm not too bothered about pretty at first, as long as we don't stop
anyway of making it pretty later; especially if non-compound types work
well.

> * Make qom-set input format consistent by switching to the matching
>   input visitor.
> 
> > Its v1 tries a different approach:
> > [PATCH 0/2] qom-get [for 2.8]
> > Message-Id: <1472117833-10236-1-git-send-email-dgilbert@redhat.com>
> > Unfortunately the mailing list archive doesn't show the full thread, so
> > you get to follow three links:
> > https://lists.gnu.org/archive/html/qemu-devel/2016-08/msg03815.html
> > https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg04261.html
> > https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg04267.html
> 
> This one stalled on string visitor limitations.  You didn't feel like
> addressing them just to get qom-get working.  Understandable.

Have there been any changes in the last 2 years that have helped?

Dave

--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK