On Tue, Nov 03, 2009 at 07:12:04PM -0500, Masami Hiramatsu wrote: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,
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
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
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... :)