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

[zhangwei(Jovi)]

On 2013/7/1 20:32, Masami Hiramatsu wrote:
> (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.
> 
Fully agree "passing recorded event entry to each action".
Actually there already have this interface, it's perf.

struct perf_event *
perf_event_create_kernel_counter(struct perf_event_attr *attr,
                                int cpu,
                                struct task_struct *task,
                                perf_overflow_handler_t callback,
                                void *context);

As we known, each event has a id, register this id in perf_event_attr, and
give a callback function, then it will call the callback function when event hit.

void overflow_callback(struct perf_event *event,
                       struct perf_sample_data *data,
                       struct pt_regs *regs)

the recorded event entry is passed as data->raw->data;

This perf interface is a generic action trigger interface now, it support
tracepoint, k(ret)probe, u(ret)probe, PMU, hw_breakpoint(perhaps we could implement
PMU and hw_breakpoint trigger in future)

So why we need to reinvent another trigger interface as this patchset did?
(this patchset changed lots of places, include macro in ftrace.h, and will change more
if support kprobe/uprobe trigger in future.)

jovi





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/