linux-kernel - Re: [PATCH 2/2] ftrace: document basic ftracer/ftracer graph needs

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]

Message-ID: <alpine.DEB.2.00.0906101523140.30552@gandalf.stny.rr.com>
Date:	Wed, 10 Jun 2009 15:34:03 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mike Frysinger <vapier.adi@...il.com>
cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] ftrace: document basic ftracer/ftracer graph needs

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:

kernel/trace/ftrace.c:

#ifndef CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST
/*
 * 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:

arch/x86/kernel/entry_64.S

ENTRY(ftrace_caller)
        cmpl $0, function_trace_stop
        jne  ftrace_stub

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
> ridiculous.

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 ;-)

-- Steve

--
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/