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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
