Hello! >>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 options. It should work via a serial line and network (UDP I guess). It 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. Maybe we don't have to re-invent the wheel. For example:
http://www.cs.unc.edu/~bbb/feathertrace/ I see. I went through the feathertrace solution documentation. I am also looking at other solutions, including Linux Trace Toolkit. I will reinvent the focus of my proposal to include the basic functionality suggested. >There is a lot to review to get the plan right here. I've made comments on the google doc proposal. Yes. I went over the comments. Thank you for such a detailed explanation. I will amend the proposal to incorporate the comments. >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. >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. I will investigate if an out of the box solution exists at the libbsd level and post it here. Regards, Vidushi On Fri, Mar 23, 2018 at 8:58 PM, Gedare Bloom <ged...@rtems.org> wrote: > 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