(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...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
