[RFC PATCH 2/4] trace: Introduce an output interface from ftrace to STM

Chunyan Zhang [off-list ref] writes:

On Tue, Jun 7, 2016 at 6:04 PM, Alexander Shishkin
[off-list ref] wrote:

quoted

Chunyan Zhang [off-list ref] writes:

quoted

This patch is introducing a new function to print Ftrace messages
to STM buffer when the traces happen.  In order to reduce the
effect on timing overhead as much as possible, only the current
function and its parent ip address will be recorded into STM in
this patch.  This idea was first introduced by Philippe Langlais
at ST-Microelectronics a long time ago[1].

So why is this useful? The value of trace points is in their payload.

Sorry, didn't get you, what did you mean by "The value of trace points" here?

I suggest that you read about ftrace usage and in particular the types
of records that end up in its ring buffer.

quoted

quoted

+#define STM_FTRACE_CHAN 0

This is why we have the stm master/channel allocation policy, which
should already assign a channel to your stm_source device when it is
linked to an stm device.

If I understand correctly, STM core can assign many channels for one
stm_source, the number we want to be allocated is specified by
'stm_source_data.nr_chans', for this patchset it's 1 for the time
being, STM_FTRACE_CHAN is the index in the range of channels allocated
to this stm_source by STM core.

Yes, I misread the code, apologies.

quoted

Also, why is this a separate compilation unit from the stm_ftrace.o?

My idea was stm_ftrace.c is part of STM driver, this patch is a
process of traces from Ftrace subsystem.  These two parts are small so
far, since this serial only added function trace exporting to STM, but
I want to add more functionalities to export more kinds of traces
which Ftrace subsystem supports to STM in the feature, my thought is
dividing into two parts like this serial did is convenient to add
other feature to each part.

Leaving aside the question of different ftrace functionalities for a
moment, what is the benefit of splitting stm_ftrace like this? The only
purpose of stm_ftrace is to take data from ftrace and send it down to an
stm device, using necessary intefaces on both ends and performing
additional framing if required.

If would make sense if the ftrace part gets a notion of "output" or
"sink" interface, which stm_ftrace can declare itself to be an
implementation of.

Regards,
--
Alex