[PATCH] Add low level event recording support

[Chris Johns]

On 23/1/19 12:34 am, Sebastian Huber wrote:
> Hello Chris,
> 
> On 20/12/2018 07:46, Sebastian Huber wrote:
>>>
>>> Sorry but I have no time to review this and consider it until next year.
>>
>> No problem, take your time. I work on this since April this year from time to
>> time, so it can wait a couple of more weeks. 
> 
> had you time to look at this?
> 

Sorry I have not.

I understand there is a need for high performance tracing and welcome this work.
I have tended to use custom code to handle this, an example is
https://git.rtems.org/rtems/tree/cpukit/dev/i2c/xilinx-axi-i2c.c#n120.

> The focus of this new stuff is the recording of high frequency events on
> multiple processors. It doesn't deal with filtering or event generation.

Like the idea but I am confused on how what is being offered fits into what we
have. It seems to provide better performance but it also overlaps some of what
we have and is missing some other things. I cannot tell from my brief look if it
sits as a component in the existing RTEMS trace framework or it is completely
separate.

I am OK with something new and better but we need to make sure what we offer is
consistent and makes sense to users. I am concerned users will become confused
if we have multiple approaches with separate code, set up, post processing and
documentation. I am fine if what we have is replaced and removed if your new
approach is to become a complete framework.

Filtering and triggering as implemented is important in some cases to make sure
the overhead and transport processes does not become unstable but it costs at
run-time. If done property the overhead could be small. Manually inserting trace
points is problematic for some users and wrapping has limitations. I am not sure
we can have a single approach for all use cases.

> Attached is a very simple example program to get the records via a TCP stream
> from the target. It outputs text like this:

How have you inserted the trace points on the target in this example? Again I am
missing the high level view. Is this in the detail of the other patch?

A common transport approach would be nice for all pieces of the trace puzzle.

> A potential GSoC project could be to use visualize this.

This would be nice and count me in helping. CTF seems to be still well supported.

Chris