[Qemu-devel] Re: Static tracepoint control via trace-event

[Jan Kiszka]

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