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

[Mike Frysinger <vapier.adi@gmail.com>]

On Wed, Jun 10, 2009 at 15:34, Steven Rostedt wrote:
>> 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.

imo, it should be a given that when a framework or common feature is
added which requires some kind of arch support, what exactly is
required of the arch should be clearly spelled out.  having an arch or
two implement said feature is useful sometimes as an example, but it
is rarely (if ever) a good place to find out details.  more time is
spent basically reverse engineering the (unfamiliar) arch details.

this isnt a complaint specific to ftrace btw, so it's more of a
general hair pulling mini rant.

> When I get time, I would love to write up a "how to port ftrace" doc.
>
> I would also love to review one ;-)

well ive already done the footwork for the basic options, so i'm
starting the documentation now by moving the Kconfig stuff i posted
there.  but it'll be missing info on:
HAVE_FTRACE_NMI_ENTER
HAVE_FTRACE_SYSCALLS
HAVE_FTRACE_MCOUNT_RECORD
HAVE_DYNAMIC_FTRACE

personally i dont care about NMI as the Blackfin arch's handling of
NMI is pretty much useless to Linux, but i would be interested in the
other three
-mike