From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ2y0-0003Hl-Pi for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:11:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ2xv-0003Ek-Ui for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:11:04 -0400 Received: from [199.232.76.173] (port=51412 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ2xv-0003ES-ED for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:10:59 -0400 Received: from mx20.gnu.org ([199.232.41.8]:61861) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJ2xv-0003pP-2K for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:10:59 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ2xu-0002an-7e for qemu-devel@nongnu.org; Tue, 23 Jun 2009 06:10:58 -0400 Message-ID: <4A40AA2D.3030202@siemens.com> Date: Tue, 23 Jun 2009 12:10:53 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20090623012944.3f4eba2e@doriath> <4A40A3D6.3080008@redhat.com> <4A40A785.2010504@siemens.com> <4A40A9EC.5070204@redhat.com> In-Reply-To: <4A40A9EC.5070204@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 09/11] QMP: Port 'info blockstats' command List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: aliguori@us.ibm.com, ehabkost@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino Avi Kivity wrote: > 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. OK... yeah, makes sense. Then the above hunk must not remove the existing monitor_printf, just add new monitor_printf_data. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux