This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH -tip perf/probes 0/5] perf-probe and kprobe-tracer updates
- From: Frederic Weisbecker <fweisbec at gmail dot com>
- To: Masami Hiramatsu <mhiramat at redhat dot com>
- Cc: Ingo Molnar <mingo at elte dot hu>, lkml <linux-kernel at vger dot kernel dot org>, Steven Rostedt <rostedt at goodmis dot org>, Jim Keniston <jkenisto at us dot ibm dot com>, Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, Christoph Hellwig <hch at infradead dot org>, "Frank Ch. Eigler" <fche at redhat dot com>, Jason Baron <jbaron at redhat dot com>, "K.Prasad" <prasad at linux dot vnet dot ibm dot com>, Peter Zijlstra <peterz at infradead dot org>, Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>, systemtap <systemtap at sources dot redhat dot com>, DLE <dle-develop at lists dot sourceforge dot net>
- Date: Wed, 4 Nov 2009 03:15:34 +0100
- Subject: Re: [PATCH -tip perf/probes 0/5] perf-probe and kprobe-tracer updates
- References: <20091104001204.3454.75999.stgit@harusame>
On Tue, Nov 03, 2009 at 07:12:04PM -0500, Masami Hiramatsu wrote:
> Hi,
>
> Here are some updates according to previous LKML threads.
> - Update perf-probe document.
> - Improve error messages.
> - Fall back to non-dwarf mode if possible.
> - Change group name to probe.
> - Rename kprobe-tracer to kprobe-event.
>
> BTW, I think perf-probe and kprobe-event might better share
> similar syntax for not confusing users. And for that purpose,
> perf-probe syntax should introduce event/group specifier,
> for example,
I personally more imagine the debugfs kprobe-event interface as
something used by higher level applications rather than users.
I've tried to use kprobe events directly by the past to do
some debugging, and once I wanted to go further a simple function
probe, like fetching a variable or putting a probe in a given branch,
it rapidly grew into a pain: I had to read assembly code, guess
which register was matching which variable, etc... It works, but
it takes too much time, and printk() rapidly becomes a temptation :)
It too low-level, but its use through perf brings all that to the
human dimension.
So, I'm not sure we really need to have such tight syntax between
both, since the debugfs more likely behaves as a gateway, something
I don't imagine to be used broadly as an end-user interface but mostly
as a kernel interface.
Especially we shouldn't break the perf probe syntax simplicity
just because we want both syntaxes to be tight.
(Nothing related to the event/group feature itself, it's just an
opinion about the need of this similarity between two interfaces).
> perf probe "newgroup:newevnt=func:10 arg1 arg2"
>
> adds the newevent under newgroup. On the other hand, ftrace
> users can also add a new event as below;
>
> echo 'newgroup:newevent=func+0x18 arg1=$a1 arg2=$a2' > kprobe_events
>
> Any thoughts?
Yeah, that would probably be nice, especially once we have a good
collection of probes to handle and to organize in a sensical output.
But it would be better to have that as an optional thing:
perf probe "[group:name=]func...."
so that we keep the simplicity of:
perf probe func
I guess you meant it as optional already, but just in case... :)
Thanks.