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

[Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>]

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