From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=36660 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1P8C6H-0001JV-Tc
	for qemu-devel@nongnu.org; Tue, 19 Oct 2010 09:20:06 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1P8BvM-0007CZ-UD
	for qemu-devel@nongnu.org; Tue, 19 Oct 2010 09:10:55 -0400
Received: from goliath.siemens.de ([192.35.17.28]:15751)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1P8BvM-0007Bt-KQ
	for qemu-devel@nongnu.org; Tue, 19 Oct 2010 09:08:16 -0400
Message-ID: <4CBD9838.6040004@siemens.com>
Date: Tue, 19 Oct 2010 15:08:08 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Static tracepoint control via trace-event
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.nongnu.org/archive/html/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: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Cc: qemu-devel <qemu-devel@nongnu.org>

Hi Stefan,

just had a closer look at qemu's new tracing framework. Looks cool,
though it leaves a bit room for improvements. ;)

One quirk I stumbled over quickly was the "disable" tag in trace-events.
It confused me first as qemu starts without any tracepoint enabled by
default and I thought I had to hack the file. Then I read the doc and
wondered which exiting or future backend would come without sufficiently
fast dynamic tracepoint control. Do you have any in mind?

Instead of making it a compile-time switch (except for simpletrace), I
would vote for declaring the simpletrace usage as the only one: disable
sets the default state of the dynamic tracepoint. That way we could use
trace-events to define a useful set of standard, moderate-impact
tracepoints that shall be on. Others will still be available once a
backend is configured, but remain off until enabled during runtime.
Anything else looks like overkill to me.

There are a few more things I have in mind (ftrace backend, enhanced
"-trace" switch, wildcards for enabling tracepoints, and more
tracepoints). Will hopefully come up with patches to address them, but
this may take a while.

Jan

PS: Do you maintain a tracing git tree?

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux