Hi! I have uploaded my final proposal pdf for GSOC'18. I have tried to incorporate all the comments made. PFA the final draft of the proposal.
Thanks for being such a wonderful community! I enjoyed every bit of the application process. Warm regards, Vidushi Vashishth GSOC_proposal_Vidushi_runtime_tracing <https://docs.google.com/document/d/1M7IUGsK3J6zqsNmyDhWKuRT69m4_SWqjftczrJKgHPM/edit?usp=drive_web> On Sat, Mar 24, 2018 at 1:23 AM, Vidushi Vashishth <reachv...@gmail.com> wrote: > 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