Messages in this thread | | | Date | Mon, 4 Feb 2013 18:20:10 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCH 5/6] uprobes/tracing: Kill uprobe_trace_consumer, embed uprobe_consumer into trace_uprobe |
| |
On 02/04, Srikar Dronamraju wrote: > > * Oleg Nesterov <oleg@redhat.com> [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.
| |