This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH v2 2.6.38-rc8-tip 0/20] 0: Inode based uprobes
- From: Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>
- To: Thomas Gleixner <tglx at linutronix dot de>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, Andrew Morton <akpm at linux-foundation dot org>, int-list-linux-mm at kvack dot org, linux-mm at kvack dot org, Peter Zijlstra <peterz at infradead dot org>, Ingo Molnar <mingo at elte dot hu>, Steven Rostedt <rostedt at goodmis dot org>, Arnaldo Carvalho de Melo <acme at infradead dot org>, Linus Torvalds <torvalds at linux-foundation dot org>, Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>, Christoph Hellwig <hch at infradead dot org>, Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, Andi Kleen <andi at firstfloor dot org>, Oleg Nesterov <oleg at redhat dot com>, Jim Keniston <jkenisto at linux dot vnet dot ibm dot com>, SystemTap <systemtap at sources dot redhat dot com>, LKML <linux-kernel at vger dot kernel dot org>, "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>
- Date: Tue, 15 Mar 2011 10:51:33 +0530
- Subject: Re: [PATCH v2 2.6.38-rc8-tip 0/20] 0: Inode based uprobes
- References: <20110314133403.27435.7901.sendpatchset@localhost6.localdomain6> <20110314163028.a05cec49.akpm@linux-foundation.org> <y0maagxuqx6.fsf@fche.csb> <alpine.LFD.2.00.1103150224260.2787@localhost6.localdomain6>
- Reply-to: Srikar Dronamraju <srikar at linux dot vnet dot ibm dot 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