Re: [PATCH v2 2.6.38-rc8-tip 0/20] 0: Inode based uprobes

[Srikar Dronamraju <srikar@linux.vnet.ibm.com>]

Hi Thomas,

> > 
> > > [...]  How do you envisage these features actually get used?
> > 
> > Patch #20/20 in the set includes an ftrace-flavoured debugfs frontend.
> 
> And you really think that:
> 
> # cd /sys/kernel/debug/tracing/
> 
> # cat /proc/`pgrep  zsh`/maps | grep /bin/zsh | grep r-xp
> 00400000-0048a000 r-xp 00000000 08:03 130904 /bin/zsh
> 
> # objdump -T /bin/zsh | grep -w zfree
> 0000000000446420 g    DF .text  0000000000000012  Base        zfree
> 
> # echo 'p /bin/zsh:0x46420 %ip %ax' > uprobe_events
> 
> # cat uprobe_events
> p:uprobes/p_zsh_0x46420 /bin/zsh:0x0000000000046420
> 
> > TODO: Documentation/trace/uprobetrace.txt
> 
> without a reasonable documentation how to use that is a brilliant
> argument?

We had a fairly decent documentation for uprobes and
uprobetracer. But that had to be changed with  the change in
underlying design of uprobes infrastructure. Since uprobetrace is one
the user interface, I plan to document it soon. However it would be
great if we had inputs on how we should be designing the syscall.

> 
> > Previous versions of the patchset included perf front-ends too, which
> > are probably to be seen again.
> 
> Ahh, probably. What does that mean?
> 
>      And if that probably happens, what interface is that supposed to
>      use?
> 
> 	The above magic wrapped into perf ?

For the initial perf probe thing, yes it would be a wrapper over
uprobe_tracer.  That is because we can reuse most of the current perf
probe and we could prototype and show users what all can be
achieved. However we plan to make perf probe depend on the syscall when
the syscall takes shape.  

> 
> 	Or some sensible implementation ?

Would syscall based perf probe implementation count as a sensible
implementation? My current plan was to code up the perf probe for
uprobes and then draft a proposal for how the syscall should look. 
There are still some areas on how we should be allowing the
filter, and what restrictions we should place on the syscall
defined handler. I would like to hear from you and others on your
ideas for the same. If you have ideas on doing it other than using a
syscall then please do let me know about the same.

I know that getting the user interface right is very important.
However I think it kind of depends on what the infrastructure can
provide too. So if we can decide on the kernel ABI and the
underlying design (i.e can we use replace_page() based background page
replacement, Are there issues with the Xol slot based mechanism that
we are using, etc), we can work towards providing a stable User ABI that
even normal users can use. For now I am concentrating on getting the
underlying infrastructure correct.


Please let me know your thoughts.

-- 
Thanks and Regards
Srikar