[PATCH] Add low level event recording support

[Sebastian Huber]

On 23/01/2019 08:23, Chris Johns wrote:
>>> 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.
>> There is no one size fits all. This stuff just solves one problem and tries to
>> do it well. You need other components that work together to get a good tracing
>> solution for RTEMS. This is a major piece of work. Providing a documentation set
>> along is a lot of work. Maybe we can use GSoC projects in this area.
> I do not think documentation is allowed as GSoC projects. It can be part of a
> development effort but not as a stand alone project.

I guess to get the data into LTTng and visualized requires some coding. 
However, I see the main effort in documentation.

>
>>> 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?
>> I tried to use the GNU ld --wrap, but this didn't work well since it wraps only
>> undefined references. I had also a look at extending GNU ld to support also
>> defined references, but this turned out to be quite difficult to me.
> I am sure. I suspect we may have to look for other solutions such as DWARF.
>
>> Some events are generated by user extensions. In the network stack I used code
>> patches. The focus of this recording stuff is not the event generation, the
>> filtering, the transport from A to B, visualization, etc. The focus is event
>> recording of high frequency events on multiprocessor platforms. It is just one
>> tiny building block that can be used in a tracing infrastructure.
> This is great to hear. Should all the existing trace code be brought together in
> libtrace?

Yes, I guess grouping the sources would help a bit, but a high level 
documentation of the tracing pieces we have would be more helpful.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.