GSOC proposal - Runtime tracing

[Vidushi Vashishth]

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.huber at 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.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.
>>
>
> 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.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180326/de6690bd/attachment-0002.html>