On Wed, 25 Nov 2015 17:50:57 +0100 Jiri Olsa <[email protected]> wrote:
> > This seems redundant. I never understood the control_ops that perf uses > > in the function tracing infrastructure. Why can't you just register the > > event->ops and have that ops set the filtering? Then the ftrace > > infrastructure will only call that event handler for the functions its > > filtered on. Then you don't need to do it again. Right now ftrace > > already does that with the generic "control_ops" that perf uses, but > > now you are doing it again. Seems rather pointless. > > well thats exactly what we are doing.. but as all ops > share single callback we need to find the proper event > this callback was triggered for The ftrace_ops has a "private" field for the user to set. Could you make that point back to the event that allocated the ftrace_ops? Then the callback function could easily get the event that matches the ftrace_ops. > > currently we use tracepoint callback (perf_tp_event) > where the proper event is found based on the event->filter > > however this is not the case for ftrace:function because > filter will not change the event->filter, but the ops filter Yeah, I'm trying to figure out the paths here. I would love to remove the control_ops as that complicates the function tracing code a bit more than I would like it to be. I just crashed function tracing by function tracing perf doing function tracing :-) I'm currently debugging that (and adding more code to help debug things like this). -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
