* Oleg Nesterov <o...@redhat.com> [2013-01-25 17:17:28]: > On 01/25, Ingo Molnar wrote: > > > > * Srikar Dronamraju <sri...@linux.vnet.ibm.com> wrote: > > > > > The other alternative is to extend the current abi and pass > > > the prefilter option. Should we extend the abi for userspace > > > tracing is obviously debatable. > > > > That's the obvious path to go - why add something to the kernel > > if user-space cannot make use of it? > > This is what I am going to (try to) do, but I am not sure if this makes > sense... > > For the start, can't we teach 'uprobe_events' file to accept, say, > > 'p file:0x1234 pid=1 other-opts'
I think this would be a very good start The only downside, I see is we would have add and remove to change the filter. Something like perf record will not be able to dynamically change the filter parameter. > > for the start? This looks simple enough, and I after looked into tools/perf > it seems that perf can be changed too. > > What do you think? > > Then we can extend 'pid=' option to accept the list of pids, perhaps. > > In the long term we probably need uprobes/pid_filter or something like this, > it should allow to add/del pid dynamically. I really do not know. Yes, I think having a file like uprobes/pid_filter would be able to dynamically change the filter. Probably when we code this up should we make this something more generic otherwise, we might end up with uid_filter, sid_filter .. Steven, Are you still pursuing multiple ftrace buffers that you proposed at LPC 2012? In which case, this new filter should also be per buffer. -- Thanks and Regards Srikar Dronamraju -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
