qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] qom: Implement qom-get HMP command


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v2] qom: Implement qom-get HMP command
Date: Fri, 09 Sep 2016 18:21:15 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

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

> * Daniel P. Berrange (address@hidden) wrote:
>> On Tue, Sep 06, 2016 at 11:18:06AM +0100, Dr. David Alan Gilbert (git) wrote:
>> > From: "Dr. David Alan Gilbert" <address@hidden>
>> > 
>> > This started off as Andreas Färber's implementation from
>> > March 2015, but after feedback from Paolo morphed into
>> > using the json output which handles structs reasonably.
>> > 
>> > Use with qom-list to find the members of an object.
>> > 
>> > (qemu) qom-get /backend/console[0]/device/vga.rom[0] size
>> > 65536
>> > (qemu) qom-get /machine smm
>> > "auto"
>> > (qemu) qom-get /machine rtc-time
>> > {
>> >     "tm_year": 116,
>> >     "tm_sec": 0,
>> >     "tm_hour": 9,
>> >     "tm_min": 46,
>> >     "tm_mon": 8,
>> >     "tm_mday": 6
>> > }
>> 
>> I'm not really a fan of us exposing JSON in the HMP, as it rather
>> seems to defeat the purpose of using the HMP.
>
> Well as long as it's clear and easily readable by humans I'm OK about it;
> and I'm less fussed about it on the output side; JSON is much more painful
> to use as human typed input.
>
>> > --
>> > v2
>> >   switched from using string-output-visitor to qobject_to_json_pretty,
>> >   drop string-output-visitor patch.
>> 
>> IIUC, you switched because string-output-visitor could not handle
>> complex types.
>> 
>> I have previously written a text-output-visitor that could do
>> this correctly, since we have this exact same requirement for
>> 'qemu-info info' to print out the extra-block specific data
>> in human friendly format for the LUKS driver.
>> 
>>   https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg01727.html
>
> How close to going in is it? It looks from the comments that Eric
> is thinking about fixing string-output-visitor.
> I'm not clear why you'd want a text-output-visitor and a 
> string-output-vistior.

Me neither.

In theory, we need two output visitors producing text, one for
machine-readable output (JSON), and the one for human-readable output.

For the latter, we use the string output visitor.

For the former, we first use the (badly named) QMP output visitor to
produce a QObject, which is then converted to JSON text by
qobject_to_json() or qobject_to_json_pretty().

Each of the two output visitors comes with a matching input visitor that
reads the same format.

To read JSON text, we first parse it into a QObject with
json_message_parser_init() & friends, which we then pass to the QMP
input visitor.

If I read Dan's cover letter correctly, the proposed text output visitor
competes with the string output visitor.  Why not enhance or replace it?

>> With your example that ought to lead to output looking like
>> 
>>  (qemu) qom-get /machine rtc-time
>>     tm_year: 116
>>     tm_sec: 0
>>     tm_hour: 9
>>     tm_min: 46
>>     tm_mon: 8
>>     tm_mday: 6
>> 
>> which i think is more suitable for the HMP.
>
> Yes, it's a little prettier; I'm not fussed either way - but I just want to
> make sure that we do end up with a qom-get; it's something I'd have found
> useful in the past and I know others would have, and the code for it was
> originally written by Andreas ~2.5 years ago - so if text-output-visitor is
> imminent then sure, but if it's not then I suggest we stick with this.

We can take qom-get as is and improve its output later.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]