From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56464) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcnqH-0005ZC-Gq for qemu-devel@nongnu.org; Wed, 15 May 2013 22:22:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UcnqG-0001m6-IL for qemu-devel@nongnu.org; Wed, 15 May 2013 22:22:53 -0400 Received: from e23smtp02.au.ibm.com ([202.81.31.144]:33555) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcnqG-0001lu-0c for qemu-devel@nongnu.org; Wed, 15 May 2013 22:22:52 -0400 Received: from /spool/local by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 16 May 2013 12:14:16 +1000 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [9.190.235.21]) by d23dlp01.au.ibm.com (Postfix) with ESMTP id A30F72CE8023 for ; Thu, 16 May 2013 12:22:40 +1000 (EST) Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r4G2MWjg15532044 for ; Thu, 16 May 2013 12:22:33 +1000 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r4G2MdbA005591 for ; Thu, 16 May 2013 12:22:39 +1000 Message-ID: <519442D1.8070402@linux.vnet.ibm.com> Date: Thu, 16 May 2013 10:22:09 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <1366968675-1451-1-git-send-email-xiawenc@linux.vnet.ibm.com> <1366968675-1451-8-git-send-email-xiawenc@linux.vnet.ibm.com> <20130426144657.GB7648@stefanha-thinkpad.redhat.com> <20130429150541.298db151@redhat.com> <5181C9D4.4000905@linux.vnet.ibm.com> <20130502080206.21df203f@redhat.com> <51832636.1020900@linux.vnet.ibm.com> <518710E7.5060103@linux.vnet.ibm.com> <20130506092224.18dbac32@redhat.com> <5192EE9D.5030604@linux.vnet.ibm.com> <20130515082848.0ec7ca4c@redhat.com> In-Reply-To: <20130515082848.0ec7ca4c@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 7/7] block: dump to monitor for bdrv_snapshot_dump() and bdrv_image_info_dump() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: kwolf@redhat.com, phrdina@redhat.com, Stefan Hajnoczi , qemu-devel@nongnu.org, armbru@redhat.com, pbonzini@redhat.com 于 2013-5-15 20:28, Luiz Capitulino 写道: > On Wed, 15 May 2013 10:10:37 +0800 > Wenchao Xia wrote: > >> 于 2013-5-6 21:22, Luiz Capitulino 写道: >>> On Mon, 06 May 2013 10:09:43 +0800 >>> Wenchao Xia wrote: >>> >>>> 于 2013-5-3 10:51, Wenchao Xia 写道: >>>>> 于 2013-5-2 20:02, Luiz Capitulino 写道: >>>>>> On Thu, 02 May 2013 10:05:08 +0800 >>>>>> Wenchao Xia wrote: >>>>>> >>>>>>> 于 2013-4-30 3:05, Luiz Capitulino 写道: >>>>>>>> On Fri, 26 Apr 2013 16:46:57 +0200 >>>>>>>> Stefan Hajnoczi wrote: >>>>>>>> >>>>>>>>> On Fri, Apr 26, 2013 at 05:31:15PM +0800, Wenchao Xia wrote: >>>>>>>>>> @@ -2586,10 +2585,12 @@ void do_info_snapshots(Monitor *mon, const >>>>>>>>>> QDict *qdict) >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> if (total > 0) { >>>>>>>>>> - monitor_printf(mon, "%s\n", bdrv_snapshot_dump(buf, >>>>>>>>>> sizeof(buf), NULL)); >>>>>>>>>> + bdrv_snapshot_dump(NULL); >>>>>>>>>> + monitor_printf(mon, "\n"); >>>>>>>>> >>>>>>>>> Luiz: any issue with mixing monitor_printf(mon) and >>>>>>>>> monitor_vprintf(cur_mon) calls? I guess there was a reason for >>>>>>>>> explicitly passing mon instead of relying on cur_mon. >>>>>>>> >>>>>>>> where are they being mixed? >>>>>>>> >>>>>>> bdrv_snapshot_dump() used a global variable "cur_mon" inside, >>>>>>> instead >>>>>>> of let caller pass in a explicit montior* "mon", I guess that is the >>>>>>> question. >>>>>> >>>>>> I'd have to see the code to tell, but yes, what Stefan described is the >>>>>> best practice for the Monitor. >>>>>> >>>>> I think this would not be a problem until qemu wants more than one >>>>> human monitor console, and then we may require a data structure to tell >>>>> where to output the string: stdout, *mon, or even stderr, and >>>>> error_printf() also need to be changed. >>>>> >>>> Luiz, what is your idea? I'd like to respin v2 if no issues for it. >>> >>> As I said before, I'd have to see the code to tell. But answering your comment, >>> the code does support multiple monitors. >>> >> Hi Luiz, >> Sorry to ask again, do you think method above is OK now, waiting for >> your confirm. > > Can you point me to the code in question? > Sure, it is + +/* + * Print to current monitor if we have one, else to stdout. It is similar with + * error_printf(). + * TODO just like error_vprintf() + */ +void message_printf(const char *fmt, ...) +{ + va_list ap; + + va_start(ap, fmt); + if (cur_mon) { + monitor_vprintf(cur_mon, fmt, ap); + } else { + vfprintf(stdout, fmt, ap); + } + va_end(ap); +} This function used global variable cur_mon instead of input parameter, similar to error_printf(). -- Best Regards Wenchao Xia