Re: [PATCH 2/2] ftrace: document basic ftracer/ftracer graph needs
From: Steven Rostedt
Date: Wed Jun 10 2009 - 15:34:21 EST
On Wed, 10 Jun 2009, Mike Frysinger wrote:
> On Wed, Jun 10, 2009 at 15:11, Steven Rostedt wrote:
> > On Wed, 10 Jun 2009, Mike Frysinger wrote:
> >> On Wed, Jun 10, 2009 at 14:45, Steven Rostedt wrote:
> >> > If there's a HAVE_XXX in Kconfig that I want to see how to implement it, I
> >> > go off and do 'grep -r XXX Documentation'.
> >> i look for the source of the define because ive given up on the
> >> Documentation actually being relevant
> > And you think documentation in Kconfig will be updated??
> i didnt mean *just* Kconfig, but funny enough, the Kconfig for
> HAVE_FUNCTION_TRACE_MCOUNT_TEST had the most relevant information.
> all other places were #ifdef with no meaning. and the existing
> x86/ppc/sh ports of ftrace are devoid of any comments let alone useful
Well that example was commented in the generic code:
* For those archs that do not test ftrace_trace_stop in their
* mcount call site, we need to do it from C.
And only x86 has it defined, thus looking at the mocunt call site
as descibed in the comment, or searching the kernel for ftrace_trace_stop:
cmpl $0, function_trace_stop
But yes, as documenting goes, this is a poor example. The
function_trace_stop is more of a way to quickly stop ftrace, in case of
emergency. It can also be useful for static ftrace. When ftrace is
enabled, there's really not much difference in overhead if it is
implemented or not. Only for static tracing, or when ftrace is disabled
via the variable (not with dynamic ftrace).
> ones, as is the core ftrace code wrt the arch pieces it relies on.
> the absolute dearth of ftrace documentation for arch porters is
Yes, we can always document more. But you are the first to complain to me
about lack of documentation for porting. I get complaints all the time
about lack of documentation for using it, and I'm working on that.
When I get time, I would love to write up a "how to port ftrace" doc.
I would also love to review one ;-)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/