From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MJ2w1-0002VQ-Nh
	for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:09:01 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MJ2vw-0002Si-Nh
	for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:09:01 -0400
Received: from [199.232.76.173] (port=51387 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MJ2vw-0002Se-I3
	for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:08:56 -0400
Received: from mx2.redhat.com ([66.187.237.31]:58181)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1MJ2vw-0002sU-0Y
	for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:08:56 -0400
Message-ID: <4A40A9EC.5070204@redhat.com>
Date: Tue, 23 Jun 2009 13:09:48 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <cover.1245730845.git.lcapitulino@redhat.com>
	<20090623012944.3f4eba2e@doriath> <4A40A3D6.3080008@redhat.com>
	<4A40A785.2010504@siemens.com>
In-Reply-To: <4A40A785.2010504@siemens.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH 09/11] QMP: Port 'info blockstats' command
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: aliguori@us.ibm.com, ehabkost@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>

On 06/23/2009 12:59 PM, Jan Kiszka wrote:
>>> --- 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?

It is.

> 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.
>    

I prefer separate printfs.  We don't want to allow choices made for the 
human protocol to influence the machine protocol, the whole point of the 
machine protocol was to have a clean break.

-- 
error compiling committee.c: too many arguments to function