Re: [PATCH -tip perf/probes 0/5] perf-probe and kprobe-tracer updates

[Frederic Weisbecker <fweisbec@gmail.com>]

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.