[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161118092905.769044bf@gandalf.local.home>
Date: Fri, 18 Nov 2016 09:29:05 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Chunyan Zhang <zhang.chunyan@...aro.org>
Cc: mathieu.poirier@...aro.org, alexander.shishkin@...ux.intel.com,
mingo@...hat.com, mike.leach@....com, tor@...com,
philippe.langlais@...com, nicolas.guion@...com,
felipe.balbi@...ux.intel.com, zhang.lyra@...il.com,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH V8 1/3] tracing: add a possibility of exporting function
trace to other places instead of ring buffer only
On Fri, 18 Nov 2016 11:07:32 +0800
Chunyan Zhang <zhang.chunyan@...aro.org> wrote:
> Currently Function traces can be only exported to ring buffer, this
> patch added trace_export concept which can process traces and export
> them to a registered destination as an addition to the current only
> one output of Ftrace - i.e. ring buffer.
>
> In this way, if we want Function traces to be sent to other destination
> rather than ring buffer only, we just need to register a new trace_export
> and implement its own .write() function for writing traces to storage.
>
> With this patch, only Function trace (trace type is TRACE_FN)
> is supported.
>
> Signed-off-by: Chunyan Zhang <zhang.chunyan@...aro.org>
This looks good to me, although I would like this to go through my tree
(to make sure it gets all my testing). I understand the next two
patches depend on this, how would you want to go about that?
One is that I can pull it in the next merge window, and the rest go in
after that. Or I can take the other two patches with the proper acks as
well.
-- Steve
Powered by blists - more mailing lists