GSoC 2016 Interested in Tracing was Re:

[Vivek Kukreja]

Sorry, I clicked on Reply by mistake instead of Reply All. Here is an offline exchange with Chris.

---

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

_______________