Re: Re: [PATCH v2 00/11] tracing: trace event triggers

[Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>]

(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