Messages in this thread | | | From | Mike Frysinger <> | Date | Wed, 10 Jun 2009 15:45:13 -0400 | Subject | Re: [PATCH 2/2] ftrace: document basic ftracer/ftracer graph needs |
| |
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
| |