[lkml]   [2013]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [GIT PULL] uprobes: pre-filtering
* Oleg Nesterov <> [2013-01-25 17:17:28]:

> On 01/25, Ingo Molnar wrote:
> >
> > * Srikar Dronamraju <> 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 ..

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

 \ /
  Last update: 2013-01-28 14:03    [W:0.084 / U:4.964 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site