This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC PATCH tracing/kprobes 0/5] tracing/kprobes, perf: perf kprobe support
- From: Ingo Molnar <mingo at elte dot hu>
- To: Masami Hiramatsu <mhiramat at redhat dot com>
- Cc: Frederic Weisbecker <fweisbec at gmail dot com>, Steven Rostedt <rostedt at goodmis dot org>, lkml <linux-kernel at vger dot kernel dot org>, Thomas Gleixner <tglx at linutronix dot de>, Arnaldo Carvalho de Melo <acme at redhat dot com>, Mike Galbraith <efault at gmx dot de>, Paul Mackerras <paulus at samba dot org>, Peter Zijlstra <a dot p dot zijlstra at chello dot nl>, Christoph Hellwig <hch at infradead dot org>, Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, Jim Keniston <jkenisto at us dot ibm dot com>, "Frank Ch. Eigler" <fche at redhat dot com>, systemtap <systemtap at sources dot redhat dot com>, DLE <dle-develop at lists dot sourceforge dot net>
- Date: Wed, 30 Sep 2009 14:04:18 +0200
- Subject: Re: [RFC PATCH tracing/kprobes 0/5] tracing/kprobes, perf: perf kprobe support
- References: <20090925191424.12939.91503.stgit@omoto> <4AC2AF01.9090202@redhat.com>
* Masami Hiramatsu <mhiramat@redhat.com> wrote:
> Masami Hiramatsu wrote:
>>
>> Hi,
>>
>> These patches introduce perf kprobe command and update kprobe-tracer.
>> perf kprobe command allows you to add new probe points by C line number
>> and local variable names.
>
> Last week, Arnaldo and I talked about this command, and he suggested
> that the command would be better 'perf probe', because it would be
> able to cover both of kernel space (by kprobes) and user space (by
> uprobes).
Agreed.
> Basically, I agree with his idea. But I think we may need to consider
> more flexible syntax for that purpose before we support uprobes. In
> this area, SystemTap has done big advance, we can see how many
> varieties of syntax it has by 'man stapprobes'.
>
> And also, it's hard to decide it without real uprobe-tracer (and
> uprobes too!) implementation on ftrace. So, I think it is better to
> continue using 'perf kprobe' in this time.
>
> But it's worth to add to todo list. :)
I'd still name it 'perf probe', even if initially it supports kprobes.
Ingo