Queries regarding Tracing related bugs and GSoC 2017

[vivek kukreja]

Hello Gedare, everyone,

I have created a ticket for the Run-Time Tracing project at:
https://devel.rtems.org/ticket/2961#ticket
The project description includes all the project ideas discussed on
the Tracing projects page. Some details in the ticket may need to be
modified for example the target RTEMS version. I'm not sure who will
be the owner/mentor for this effort so I have left it blank for now.

Meanwhile I have put up the first draft of my proposal on the RTEMS
GSoC 2017 page. Here is the link:
https://docs.google.com/document/d/1-IoZwnO1W914SJnTTeoLD6ljHJZqKBNvqZdn2gfUtkc/edit?usp=sharing
I would request you and other concerned experts to review my proposal
and suggest any modifications.

I'm also looking into the timeout errors I faced in the capture and
fileio examples. I will try to resolve these issues at the earliest.

Regards,
Vivek

On Wed, Mar 22, 2017 at 9:13 PM, Gedare Bloom <gedare at rtems.org> wrote:
> On Sun, Mar 19, 2017 at 11:23 AM, vivek kukreja <vivekkukreja5 at gmail.com> wrote:
>> Hello developers,
>>
>> I have worked on CTF tracing last year under GSoC. I was working on my
>> previous deliverables and i noticed there are some bugs in the current
>> capture and function tracing examples on qemu for arm/xilinx_zynq_a9,
>> related to recent updates made to TCB and termios implementation. I'm
>> working on resolving these issues so I can merge my previous changes.
>> I have mailed Chris regarding this and I was suggested to ping the
>> developer list for further clarification on these errors, and whether
>> I should create any tickets.
>>
> Good. Probably you should have a ticket related to the project. Maybe
> create a GSoC Project ticket.
>
>> I also wanted to enquire about the status of the Live tracing project
>> this year in GSoC. I'm considering the following ideas for a proposal,
>> once the tracing support is re-established:
>>
>> 1. libDWARF integration: I've been studying libDWARF for
>> functionalities that can be ported to RTEMS, for the purpose of
>> finding function signatures and variable types to be traced by the
>> trace linker. This can be used to auto-configure the signatures/types
>> at the trace linking phase of an application.
>>
>> 2. Transports API: In GSoC 2016 I worked on transport for moving
>> traces to host. I investigated serial and USB transport apart from
>> ethernet using libBSD. There is discussion on the Tracing projects
>> page about integrating all transports and providing an API for custom
>> transports in the application for both capture and function tracing.
>>
>> 3. Live tracing: In capture tracing, the trace process has to be
>> paused before reading the trace (as discussed with Jennifer Averrett,
>> the previous contributor). I'm looking at alternatives like copying
>> the unsafe buffer to a new one which can in turn be dumped on host
>> using NFS or other transport options. We can create a low priority
>> task for this purpose, along with the trace buffering functions
>> defined in rtld-trace-buffer.ini.
>>
>> Please suggest any improvements or additions to the above ideas. Also
>> I dont know if there is any interest in this project for GSoC 2017 but
>> I would like to merge my previous changes soon nonetheless.
>>
> This continues to be an important area to support. I suspect a
> "Transports API" would be a good beneficial project to scope out and
> understand. Without Transports, it is hard to create a uniform
> approach to live tracing that would work well across Architectures/BSP
> families.
>
>> Regards,
>> Vivek
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel