On 02/04, Srikar Dronamraju wrote: > > * Oleg Nesterov <[email protected]> [2013-01-31 20:18:29]: > > > trace_uprobe->consumer and "struct uprobe_trace_consumer" add the > > unnecessary indirection and complicate the code for no reason. > > > > This patch simply embeds uprobe_consumer into "struct trace_uprobe", > > all other changes only fix the compilation errors. > > I know this patch doesnt change the current behaviour.
Yes, and it makes the code simpler. > We dont handle two concurrent perf record sessions for the same user > space probe. Since both sessons share the same trace_uprobe and hence > share the same consumer. We do? I am testing the patches I am going to send, and I specially tried to verify that 2 concurent sessions with different/same filtering constraints work fine. Or I misunderstood what you meant... > Initially I had thought of having a chain in > uprobe_trace_consumer. However we dont get have enough information at > the probe_event_disable() time to detect which consumer to delete Hence > I dropped the idea of having a list of consumers attached to the > trace_uprobe. You know, until recently I knew absolutely nothing about kernel/events/ and kernel/trace/. Not that I really understand this code now, I can be easily wrong. But so far I think that a chain of multiple consumers makes no sense. Each consumer->handler() will use the same call->perf_events list, this will only complicate the code for no reason. > However with allowing prefiltering, we need to have ability to > distinguish consumers. Certainly not. Please see the patches I am going to send. Oleg. -- 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/
