Hello Vidushi, Sebastian: On Fri, Mar 23, 2018 at 2:16 AM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > Hello Vidushi, > > the RTEMS Trace Linker is definitely an interesting tool to track down > difficult and specific issues. However, this is a nice to have optional
out-of-box Trace Linker with integration to debugger or CTF tools will be highly beneficial for the "user-side" experience of RTEMS. This can be quite beneficial for marketing if nothing else. :) Given the current state, and that we've had a few projects already on this topic, any project working here needs to focus on delivering a complete slice of the software stack from trace configuration all the way through trace output analysis. There is a lot to review to get the plan right here. I've made comments on the google doc proposal. > feature from my point of view. We should focus on basic functionality and > this is interrupt entry/exit and thread switching. This should work out of > the box without having to compile RTEMS with specialized configuration I agree that this is also an important aspect for "kernel-level" tracing, and it should be implemented directly into RTEMS with standard configuration (configure or confdefs.h options). The requirements for this functionality is unclear, though, such as what the trace output should be. > options. It should work via a serial line and network (UDP I guess). It I don't see how network support can exist out-of-the-box unless the solution exists at libbsd level. I think there will be two pieces to this kind of project: 1. capturing traces to memory buffers from interrupt/"kernel" contexts. 2. transporting buffers via worker threads. Then, one can implement a basic worker thread using available drivers in rtems, and also more advanced (network) workers relying on libbsd. > should also support SMP machines. This requires per-processor trace buffers. > The trace buffer should work without locks, e.g. only interrupt > disable/enable. I would do also a short review of existing trace solutions. The use of per-processor buffers makes the "reader" side (transport) more complicated. This is a good place to consider a wait-free non-blocking data structure, or a rwlock with writer prioritization. At any rate, a good design is needed here with some careful thought. > Maybe we don't have to re-invent the wheel. For example: > > http://www.cs.unc.edu/~bbb/feathertrace/ > > -- > 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
