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

[Markus Armbruster]

"Dr. David Alan Gilbert" <address@hidden> writes:

> * Markus Armbruster (address@hidden) wrote:
>> Markus Armbruster <address@hidden> writes:
>> 
>> > Andreas Färber <address@hidden> writes:
>> >
>> >> Am 08.06.2018 um 11:41 schrieb Dr. David Alan Gilbert:
>> >>> * Andreas Färber (address@hidden) 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: <address@hidden>
>> > 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.

We've waited so long for "someone" to post a solution that satisfies all
wants.  We should take a solution that is useful and can grow.

>> * 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: <address@hidden>
>> > 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?

There's been progress, but there are gaps left.

Back then, we had the choice of string input/output visitors, and the
options visitor, all (severely) restricted to certain kinds of data.

Now we have the qobject keyval input visitor, which is almost general.
There is no matching output visitor, yet, simply because we haven't had
the need.