From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50860 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P8CWZ-0004Cv-Ea for qemu-devel@nongnu.org; Tue, 19 Oct 2010 09:46:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P8CWX-0000Wc-8T for qemu-devel@nongnu.org; Tue, 19 Oct 2010 09:46:42 -0400 Received: from david.siemens.de ([192.35.17.14]:17978) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P8CWW-0000W5-VX for qemu-devel@nongnu.org; Tue, 19 Oct 2010 09:46:41 -0400 Message-ID: <4CBDA13B.1070904@siemens.com> Date: Tue, 19 Oct 2010 15:46:35 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4CBD9838.6040004@siemens.com> <20101019133057.GA3950@stefan-thinkpad.transitives.com> In-Reply-To: <20101019133057.GA3950@stefan-thinkpad.transitives.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Stefan Hajnoczi Cc: qemu-devel Am 19.10.2010 15:30, Stefan Hajnoczi wrote: > 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. Another to-do item is to remove the strange dependency of tracing managements features on CONFIG_SIMPLE_TRACE. That way the monitor commands and a to-be-added command line option to control individual tracepoints could of course also be used by an ftrace backend. I bet the DTrace backend will like to see this as well. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux