GSOC proposal - Runtime tracing

[Vidushi Vashishth]

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 <reachvidu at 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 <gedare at rtems.org> wrote:
>
>> Hello Vidushi, Sebastian:
>>
>> On Fri, Mar 23, 2018 at 2:16 AM, Sebastian Huber
>> <sebastian.huber at 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.huber at embedded-brains.de
>> > PGP     : Public key available on request.
>> >
>> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> >
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180326/dc12c5bd/attachment-0002.html>