GSoC 2016 Interested in Tracing was Re:

Thu Mar 17 08:10:20 UTC 2016

Hi Chris,
Sorry for the delay. I was caught up with my college assessments.
First draft of my proposal is up and open for comments. I'm going
through the Capturing Engine documentation now and the Project
description will be modified once i hear your suggestions.

Also git services are working now since i will be using a different
internet connection henceforth.
I will setup RTEMS using the latest git repo and see if the error in
the fileio tracing example is resolved and send a patch for the
missing include statement at the earliest.

Regards,
Vivek

________________________________________
From: Chris Johns <chrisj at rtems.org>
Sent: 16 March 2016 10:18
To: Vivek Kukreja; gutekunst at gmail.com
Cc: Gedare Bloom
Subject: Re: GSoC 2016 Interested in Tracing was Re:

Hi,

I have reviewed your document but I could no actual proposal in the
Google Document https://goo.gl/8jRfyV.

I have updated the proposal template so please check it against your one.

I suggest you fill in each section answering the questions provided.

Thanks.
Chris

> On 15/03/2016 00:22, Vivek Kukreja wrote:
> Hello Chris, Isaac
> 
> Sorry for the delay in adding a student proposal on https://devel.rtems.org/wiki/GSoC/2016. Its still in progress meanwhile i am looking at alternate ways of accessing git. I have not heard from Isaac regarding his interest in mentoring the project but I hope Chris will comment on the proposal once it takes shape.
> 
> Also regarding an issue i posted earlier about the trace buffering example described on https://devel.rtems.org/wiki/Developer/Tracing/Trace_Buffering, i was getting an error on running the rtems-tld command(fileio-wrapper.c:388:13: error: dereferencing pointer to incomplete type 'struct Thread_Control') .
> I found that there is an include statement in the online repo of rtld-trace-buffer.ini file thats somehow missing from my installation(at  development/rtems/4.12/share/rtems/trace-linker)
> "#include<rtems/rtems/tasksimpl.h>"
> Now the tracing example successfully builds.
> 
> Regards,
> Vivek
> ________________________________________
> From: Chris Johns <chrisj at rtems.org>
> Sent: 10 March 2016 08:11
> To: Vivek Kukreja
> Cc: gutekunst at gmail.com; Gedare Bloom
> Subject: Re: GSoC 2016 Interested in Tracing was Re:
> 
>> On 10/03/2016 06:39, Vivek Kukreja wrote:
>> Hello Chris, Isaac
>> I have run the modified hello world example and created a patch for it. I cannot access your git server from my institute probably because of some firewall issues. I will look into it.
> 
> Please keep me posted about the git access.
> 
>> Following is the output of diff command:
>> --- rtems-4.11.0-rc1master/testsuites/samples/hello/init.c 2015-12-13 04:22:53.000000000 -0800
>> +++ rtems-4.11.0-rc1/testsuites/samples/hello/init.c 2016-03-09 10:35:51.527042759 -0800
>> @@ -28,7 +28,7 @@
>>   )
>>   {
>>     rtems_test_begin();
>> -  printf( "Hello World\n" );
>> +  printf( "Hello World- Modified by Vivek Kukreja 2016\n" );
>>     rtems_test_end();
>>     exit( 0 );
>>   }
> 
> The https://devel.rtems.org/wiki/GSoC/GettingStarted pages asks you to
> post to the lists your patch and then update the GSoC 2016 page at
> https://devel.rtems.org/wiki/GSoC/2016. Can you please do this? Thanks.
> 
>> 
>> I have gone through some recent archives of the IRC and i have some questions:
>> 
>> 1. RTEMS trace linker uses function wrapping to instrument linked files of app to interact with capture engine(on-target) and fetching trace data. As Isaac has described in this archive https://www.mail-archive.com/devel@rtems.org/msg06199.html, barectf is a tool used for tracing user-defined data/structs. Is it required and feasible as a GSOC project to create support for this feature? As Chris said this would require deciding the structure of things a bit.
>> Also, can you throw some light on 'target integration' of the capture engine with rtems-tld and what tasks does it entail currently?
> 
> I have updated the Open Project TraceTool wiki page. Please see have a
> look and see if that answers your questions.
> 
>> 2. LTTng and barectf support CTF generation. Its required that app/kernel files linked using RTEMS trace linker generate either native CTF data or trace-data that can be converted to CTF. Could you share some pointers/links to understand the current architecture for CTF generation in RTEMS?
> 
> Currently there is no CTF support in RTEMS.
> 
>> I think this feature has few prerequisites yet many features will use this. For example: live trace-reading(over TCP/IP) as Isaac suggested.
> 
> Live trace is a function of the back end of the Capture Engine. The
> Capture Engine at it's top takes in records from generated by barectf
> and buffers them and at it's back end it interfaces to transports to get
> the data off the target. This architecture disconnects the transport
> from the tracing and allows different transports to be used. For example
> it could TCP, or UDP, JTAG, SPI, or a UART. RTEMS users have a wide
> range of hardware and often debug interfaces are unique because of the
> costs they can add to hardware. Consider a satellite, adding a whole
> network interface, MAC and TCP/IP stack to trace during development is
> silly because there is no network in space yet all the hardware would
> need to be provided for and at a minimum it would take valuable board
> space. The key role of the Capture Engine is to provide a simple API for
> the transport layers. This work in the Capture Engine is either
> partially done or needs to be done.
> 
> A key function of the Capture engine is to provide concurrent buffering.
> This means low overhead buffering safe in an SMP context. This is harder
> than it appears. Keeping it separate from barectf and rtems-tld is
> important.
> 
>> 
>> I'm not sure how ambitious these projects are but given a chance i would like to work on native CTF generation and live trace-reading with Isaac. Providing support for tracing user-defined structs(like barectf) sounds interesting too if that feature is required before CTF.
> 
> These are good GSoC tasks and we welcome your interest in the work.
> 
> Chris
> 