lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 4 Nov 2009 03:15:34 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Masami Hiramatsu <mhiramat@...hat.com>
Cc:	Ingo Molnar <mingo@...e.hu>, lkml <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Jim Keniston <jkenisto@...ibm.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Christoph Hellwig <hch@...radead.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Jason Baron <jbaron@...hat.com>,
	"K.Prasad" <prasad@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	systemtap <systemtap@...rces.redhat.com>,
	DLE <dle-develop@...ts.sourceforge.net>
Subject: Re: [PATCH -tip perf/probes 0/5] perf-probe and kprobe-tracer
	updates

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ