Messages in this thread | | | Date | Mon, 01 Jul 2013 21:32:54 +0900 | From | Masami Hiramatsu <> | Subject | Re: Re: [PATCH v2 00/11] tracing: trace event triggers |
| |
(2013/06/29 18:30), zhangwei(Jovi) wrote: >> This patchset implements 'trace event triggers', which are similar to >> the function triggers implemented for 'ftrace filter commands' (see >> 'Filter commands' in Documentation/trace/ftrace.txt), but instead of >> being invoked from function calls are invoked by trace events. >> Basically the patchset allows 'commands' to be triggered whenever a >> given trace event is hit. The set of commands implemented by this >> patchset are: >> >> - enable/disable_event - enable or disable another event whenever >> the trigger event is hit >> >> - stacktrace - dump a stacktrace to the trace buffer whenever the >> trigger event is hit >> >> - snapshot - create a snapshot of the current trace buffer whenever >> the trigger event is hit >> >> - traceon/traceoff - turn tracing on or off whenever the trigger >> event is hit >> >> Triggers can also be conditionally invoked by associating a standard >> trace event filter with them - if the given event passes the filter, >> the trigger is invoked, otherwise it's not. (see 'Event filtering' in >> Documentation/trace/events.txt for info on event filters). >> > > I just aware that we are implementing more and more scripting functionality into > tracing subsystem, like filter and trigger mode, of cause we don't call it > as scripting, but basically the pattern is same, all is "do something when event hit".
Agreed, that's a good direction to handle event by script in kernel :) That may be simply done with an extension of "event trigger". Of course your ktap work will be the next step for ftrace. But I think, the basic implementation can be done by just passing recorded event entry to each action. (other works are for debugfs management) And that could be a generic trace-event interface for other users too.
> > FYI, a pretty simple scripting module of tracing is there: > https://github.com/ktap/ktap.git > > For the trigger mode, you can perform any command when event hit if using scripting, > in contrast with this patchset, ktap use perf callback handler to invoke command, > so it don't need extra code to support trigger mode in tracepoint/k(ret)probe/u(ret)probe. > > --------------------- > trace "syscalls:*" function (e) { > printf("%d %d\t%s\t%s", cpu(), pid(), execname(), e.tostring()) > } > --------------------- > trace "probe:do_sys_open dfd=%di filename=%dx flags=%cx mode=+4($stack)" function (e) { > printf("%d %d\t%s\t%s", cpu(), pid(), execname(), e.tostring()) > } > --------------------- > trace "probe:do_sys_open%return fd=$retval" function (e) { > printf("%d %d\t%s\t%s", cpu(), pid(), execname(), e.tostring()) > } > --------------------- > trace "probe:/lib/libc.so.6:0x000773c0" function (e) { > printf("%d %d\t%s\t%s", cpu(), pid(), execname(), e.tostring()) > }
Nice! so the ktap can use perf probe to define new events - without involving any dwarf hacks :)
> what I'm thinking now is perhaps we can use a more generic mechanism in future > to let user do more magic things when event hit. > > To be clear, I'm not against on this patchset, I'm on the same side with Tom, > the trigger mode of this patchset is useful(awesome work). I'm just sharing some extra info, > hopeful you don't mind it :)
Thank you!
-- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com
| |