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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
