On Tue, Oct 19, 2010 at 2:36 PM, Daniel P. Berrange <berra...@redhat.com> wrote: > On Tue, Oct 19, 2010 at 03:08:08PM +0200, Jan Kiszka wrote: >> Hi Stefan, >> >> just had a closer look at qemu's new tracing framework. Looks cool, >> though it leaves a bit room for improvements. ;) >> >> 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. > > FYI with the DTrace/SystemTAP backend I posted yesterday, the 'disable' > keyword is effectively completely ignored. All tracepoints are disabled > when QEMU is running normally. Only when a end user runs a dtrace script > that references a QEMU tracepoint, is that specific tracepoint enabled.
I think that makes sense for external trace backends. DTrace can launch a process for you with the probes you want enabled from the start. The simpletrace backend can't really do this so probes can be enabled/disabled at compile-time (e.g. early startup tracing). Stefan
