hi! > I think we should define some basic functionality which should be available ready to use during mid term evaluation. I want to avoid a last minute delivery during the project end with no time to fix problems after a review. This likely results in some half-finished work which nobody can use.
Currently I plan to deliver a barectf integrated RTEMS trace linker and a transport mechanism to deliver trace data to the host machine using TCP by mid term evaluation (second phase). I intend to fix any errors encountered in the process by end of second phase itself. I understand how kernel level tracing will be beneficial to the tracing framework. I can modify my proposal to include this as one of my goals. I also intend to deliver live tracing functionality as a goal of my third phase. Would it be viable to accommodate kernel level tracing to my current plan? Or should I discount any of my current goals (integration of barectf, transport mechanism to host, live tracing) in place of it? Regards, Vidushi Vashishth On Mon, Mar 26, 2018 at 12:17 PM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 23/03/18 16:28, Gedare Bloom 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. >> > > I think we should define some basic functionality which should be > available ready to use during mid term evaluation. I want to avoid a last > minute delivery during the project end with no time to fix problems after a > review. This likely results in some half-finished work which nobody can use. > > >> 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. >> > > The network transport should rely on the POSIX sockets API only as defined > by Newlib. > > >> 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. >> > > Everything which uses an atomic read-modify-write operation on some global > data will lead to a significant change in the overall timing on larger > machines with several cache layers (e.g. QoriIQ T4240). The reader side > with per-processor data is not that difficult if everything runs in > kernel-space. You can use processor affine threads (supported by the > default SMP scheduler) or inter-processor interrupts to fetch the data. > > >> Maybe we don't have to re-invent the wheel. For example: >>> >>> http://www.cs.unc.edu/~bbb/feathertrace/ >>> >> > This was just one example. > > > -- > 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
