(offlist) Re: GSoC 2016 Interested in Tracing was Re:

Thu Mar 17 15:27:09 UTC 2016

Hello Isaac,
Thanks for your suggestions on my proposal. I will use your personal email for future correspondence. I have a few questions:
Can you please share some use-cases for tracing that developers are interested in?
I would like to understand the features you require at Vecna and the flow of how tracing should work for your purpose.
Also can you give an overview about the lttng-live functionality you have implemented and how its used? And how it can be improved using CTF?

Regards,
Vivek

> On 17-Mar-2016, at 17:54, Isaac Gutekunst <isaac.gutekunst at vecna.com> wrote:
> 
> I Vivek,
> 
> Thanks for the proposal. I am looking it over now!
> 
> Welcome to the program and hello!
> 
> A bit about me: I'm an embedded firmware engineer at Vecna Technologis (vecna.com). We are using RTEMS
> here for our next generation robotics platform. We are also committed to helping RTEMS through open source
> contributions, including mentoring GSoC students.
> 
> I'm really excited that you are interested in trace. There are a lot of fascinating and fundamental concepts lurking
> within. There is also a huge opportunity to provide a feature which brings RTEMS closer to feature parity with some
> of the most expensive commercial RTOSs. That's pretty awesome! I'm personally really excited because this functionality
> has immediate use cases for our robotic work here. I've already done a decent amount of unreleased work adding
> lttng-live functionality to one of our projects. It's super alpha quality, and written in C++ which might limit its
> usefulness.
> 
> I also have a system for emitting trace messages into a different buffer (not the RTEMS Capture Engine), since I needed
> to test it on Linux.
> 
> 
> Chris: Does the current capture engine allow simultaneous reading and writing of trace data? This is an important feature for
> us at Vecna, and I imagine would be useful to others. Especially with lttng-live support.
> 
> Chris: Should most communication be typically be done on the rtems-devel mailing list?
> 
> Another note:
> 
> You seem to have received the wrong email address. For GSoC I will either be using this email (from work),
> or igutekunst at gmail.com (personal email associated with the GSoC website).
> 
> Isaac
> 
>> On 03/17/2016 04:10 AM, vivek kukreja wrote:
>> 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.
>> g and fundamental concepts lurking
> within. There is also a huge opportunity to provide a feature which brings RTEMS closer to feature parity with some
> of the most expensive commercial RTOSs. That's pretty awesome! I'm personally really exc
>> 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
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>> 