* Markus Armbruster (arm...@redhat.com) wrote: > Markus Armbruster <arm...@redhat.com> writes: > > > Andreas Färber <afaer...@suse.de> writes: > > > >> Am 08.06.2018 um 11:41 schrieb Dr. David Alan Gilbert: > >>> * Andreas Färber (afaer...@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-dgilb...@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-dgilb...@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 / dgilb...@redhat.com / Manchester, UK
