From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33787 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P8CHR-0001g4-NP for qemu-devel@nongnu.org; Tue, 19 Oct 2010 09:31:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P8CHM-0004DD-Rx for qemu-devel@nongnu.org; Tue, 19 Oct 2010 09:31:05 -0400 Received: from mtagate5.uk.ibm.com ([194.196.100.165]:36786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P8CHM-0004Cp-Jm for qemu-devel@nongnu.org; Tue, 19 Oct 2010 09:31:00 -0400 Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate5.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o9JDUwet006405 for ; Tue, 19 Oct 2010 13:30:58 GMT Received: from d06av11.portsmouth.uk.ibm.com (d06av11.portsmouth.uk.ibm.com [9.149.37.252]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o9JDUwmd3330264 for ; Tue, 19 Oct 2010 14:30:58 +0100 Received: from d06av11.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o9JDUwvj014184 for ; Tue, 19 Oct 2010 07:30:58 -0600 Date: Tue, 19 Oct 2010 14:30:58 +0100 From: Stefan Hajnoczi Message-ID: <20101019133057.GA3950@stefan-thinkpad.transitives.com> References: <4CBD9838.6040004@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CBD9838.6040004@siemens.com> Subject: [Qemu-devel] Re: Static tracepoint control via trace-event List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel On Tue, Oct 19, 2010 at 03:08:08PM +0200, Jan Kiszka wrote: > 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. The motivation for "disable" producing a nop trace event is that it allows QEMU builds without certain trace events. A trace event cannot simply be removed by deleting its trace-events declaration since there are calls to its trace_*() function in the source tree. So this provided a way to disable trace events before simpletrace supported enabling/disabling trace events at runtime :). Today that's no longer an issue for simpletrace and other tracing backends like LTTng UST and SystemTAP handle disabled trace events well. I agree that keeping just one meaning for the "disable" keyword is better. Perhaps we should keep a separate "nop" keyword to build out specific trace events. When would "nop" be handy? I think an ftrace backend is a good example. Since an ftrace marker cannot be enabled/disabled at runtime, the only way to silence unwanted trace events is to "nop" them at compile-time. > 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. Sounds great. > PS: Do you maintain a tracing git tree? No, I'm reviewing patches as they are posted for qemu-devel. If the backlog between mailing list discussion and merge reaches the point where your patches are suffering conflicts please let me know and I can maintain one. For the initial QEMU tracing effort I kept a tree but I stopped after the patches were accepted into mainline. The patches I write go straight to qemu-devel now. Stefan