I have read the ticket and not the patch. On 20/12/2018 08:00, Joel Sherrill wrote: > How does this relate.to <http://relate.to> the existing infrastructure for the > capture engine? It seems duplicative.
Yes it is confusing. With this change we would have 3 possible trace systems, the capture engine, rtems-tld and this. I would like just one way to trace a live system. I am OK with the capture engine being replaced with something new and better that provides all the functionality of the capture engine, ie triggers, floors etc. The ticket does not state if this is what will happen. It would be good if this can be clarified. Filtering at runtime is an important performance consideration. It is also not clear to me why the capture engine cannot be improved to have the capture method presented here integrated. Sure, currently it does not have the low level performance because of the locks used but it is not clear to me why this code cannot be changed? Can we please establish the requirements and how this sits with what we have sorted out before reviewing patches and details? An important part of any trace work is host integration and the tools to manage this. Getting data off via TCP, UDP, file etc is only part of the problem so it would good to know what the integration path on the host is. Sorry but I have no time to review this and consider it until next year. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
