see git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git branch tracing/ftrace functions in include/linux/ftrace.h, [...]register_ftrace_function()
probably needs kernel changes for: ... module-friendly ftrace registration api ... and a data (argument) passing mechanism
(In reply to comment #0) > see git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git FYI, recently, Ingo changed name of his tree. http://www.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-ftrace.git
Anonymous word-of-mouth from a colleague of the ftrace team suggests an intention on their part to produce a module-facing interface for the widget. Once that exists, we can make systemtap work with it.
https://bugzilla.redhat.com/show_bug.cgi?id=454694
(In reply to comment #1) > probably needs kernel changes for: > ... module-friendly ftrace registration api I think this should be done by simply exporting register/unregister_ftrace_function(). > ... and a data (argument) passing mechanism Arguments passing is hard because of mcount implementation. It will give us just caller ip and callee ip. So, in the first phase, might we support only $caller and $callee in ftrace-based probe?
> > probably needs kernel changes for: > > ... module-friendly ftrace registration api > I think this should be done by simply exporting > register/unregister_ftrace_function(). Hooking into the "dyn-ftrace" functionality seems more relevant, since that is what we'd need to choose only subsets of kernel functions to probe. The register_ftrace_function widget seems to be suited only for a separate abstract event source that traps\*all* function entries. > > ... and a data (argument) passing mechanism > > Arguments passing is hard because of mcount implementation. > It will give us just caller ip and callee ip. > So, in the first phase, might we support only $caller and $callee in > ftrace-based probe? I was not talking about accessing contextual data registers via ftrace. We'll have to work somewhat hard to make that work at all. What I was referring to was a callback void* parameter that allows us to tell apart potentially multiple registrations -- like the kprobe* pointer we get back from kprobe callbacks.
With srostedt's linux commit 936e074b, we now have ftrace function hooking facilities available. See ftrace_register_*, ftrace_set_*.
Steve Rostedt's ftrace/kprobes integration patches may make this unnecessary. https://lkml.org/lkml/2011/8/10/337
The kprobes-via-ftrace widget was merged into linux 3.9.