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 :|
