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

[Daniel P. Berrange]

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. 

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|