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
