qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH 09/11] QMP: Port 'info blockstats' command


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH 09/11] QMP: Port 'info blockstats' command
Date: Tue, 23 Jun 2009 11:59:33 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

Avi Kivity wrote:
> On 06/23/2009 07:29 AM, Luiz Capitulino wrote:
>> Signed-off-by: Luiz Capitulino<address@hidden>
>> ---
>>   block.c   |   18 +++++++++---------
>>   monitor.c |    3 ++-
>>   2 files changed, 11 insertions(+), 10 deletions(-)
>>
>> diff --git a/block.c b/block.c
>> index aca5a6d..3b4af27 100644
>> --- a/block.c
>> +++ b/block.c
>> @@ -1102,15 +1102,15 @@ void bdrv_info_stats(Monitor *mon)
>>       BlockDriverState *bs;
>>
>>       for (bs = bdrv_first; bs != NULL; bs = bs->next) {
>> -        monitor_printf(mon, "%s:"
>> -                       " rd_bytes=%" PRIu64
>> -                       " wr_bytes=%" PRIu64
>> -                       " rd_operations=%" PRIu64
>> -                       " wr_operations=%" PRIu64
>> -                       "\n",
>> -                       bs->device_name,
>> -                       bs->rd_bytes, bs->wr_bytes,
>> -                       bs->rd_ops, bs->wr_ops);
>> +        monitor_printf_data(mon, "%s:"
>> +                            " rd_bytes=%" PRIu64
>> +                            " wr_bytes=%" PRIu64
>> +                            " rd_operations=%" PRIu64
>> +                            " wr_operations=%" PRIu64
>> +                            "\n",
>> +                            bs->device_name,
>> +                            bs->rd_bytes, bs->wr_bytes,
>> +                            bs->rd_ops, bs->wr_ops);
>>    
> 
> It may be easier for control mode to drop the variable= prefixes (they
> are described in the spec anyway).
> 

Isn't monitor_printf_data also used for pretty-printing in case of
human-operated monitors? I think we need to keep this - or provide two
output formats which are filtered by the monitor based on the the target
terminal's mode. But that sounds like a lot of work /wrt conversion and
long-term maintenance.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux




reply via email to

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