From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48536 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ON8Sh-0004gE-9j for qemu-devel@nongnu.org; Fri, 11 Jun 2010 13:56:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ON8Sf-0002SE-JD for qemu-devel@nongnu.org; Fri, 11 Jun 2010 13:56:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4863) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ON8Sf-0002S5-6P for qemu-devel@nongnu.org; Fri, 11 Jun 2010 13:56:09 -0400 Date: Fri, 11 Jun 2010 14:56:01 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] [RFC v2] [PATCH 0/3] Monitor Support for 'simple' trace backend Message-ID: <20100611145601.64a1a31b@redhat.com> In-Reply-To: <4C122758.4020808@siemens.com> References: <20100611003811.2635fa5d@zephyr> <4C122758.4020808@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Anthony Liguori , Hajnoczi , "kvm@vger.kernel.org" , Stefan@gnu.org, "qemu-devel@nongnu.org" , Markus Armbruster , "maneesh@linux.vnet.ibm.com" , "ananth@linux.vnet.ibm.com" , Prerna Saxena On Fri, 11 Jun 2010 14:08:56 +0200 Jan Kiszka wrote: > Markus Armbruster wrote: > > Prerna Saxena writes: > > > >> This is v2 of monitor commands based on Stefan's trace framework : > >> ( http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg02407.html ) > >> > >> This adds the following monitor commands for the 'simple' backend: > >> - info trace : to view current contents of the trace buffer. > >> - info tracepoints : to view all available tracepoints and their > >> state. > >> - tracepoint NAME on|off: to enable/disable the logging of data from > >> tracepoint 'NAME'. > >> > >> > >> Changelog : > >> - Command 'info trace' is used to view current contents of buffer, in > >> place of 'trace'. > >> - Cleanups > > > > Do we want this in QMP? > > For sure IMO. Maybe not in a hurry to avoid breakages until the whole > tracing infrastructure has settled, but long-term to ease scripting etc. Yeah, that's why I didn't suggest it in my review. > Still, let's not add this as an old-style monitor command, rather > convert it to the new style, maybe blocking QMP for now. I'll post the > required infrastructure for that blocking along my next device_show > series (hopefully the next days). Agreed.