From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36355 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P8DCt-00073T-1T for qemu-devel@nongnu.org; Tue, 19 Oct 2010 10:30:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P8DCr-0004bS-Sd for qemu-devel@nongnu.org; Tue, 19 Oct 2010 10:30:26 -0400 Received: from david.siemens.de ([192.35.17.14]:20298) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P8DCr-0004bF-JJ for qemu-devel@nongnu.org; Tue, 19 Oct 2010 10:30:25 -0400 Message-ID: <4CBDAB7D.7090409@siemens.com> Date: Tue, 19 Oct 2010 16:30:21 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Static tracepoint control via trace-event References: <4CBD9838.6040004@siemens.com> <20101019133057.GA3950@stefan-thinkpad.transitives.com> <4CBDA13B.1070904@siemens.com> <20101019141230.GJ23535@redhat.com> In-Reply-To: <20101019141230.GJ23535@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Stefan Hajnoczi , qemu-devel Am 19.10.2010 16:12, Daniel P. Berrange wrote: > On Tue, Oct 19, 2010 at 03:46:35PM +0200, Jan Kiszka wrote: >> 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. > > I don't see a need for any monitor commands or command line options > for the DTrace backend, since everything is completely dynamically > controlled based on the tracing scripts the user is running. Ah, it's all dynamic probing, you just need the marks. OK, was a bad example. :) Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux