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

Thu Mar 17 15:44:42 UTC 2016

Hi Vivek,

Let's get Chris involved in this discussion. He is the main mentor here and knows more about the direction the project should go.

On 03/17/2016 11:27 AM, vivek kukreja wrote:
>
> 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.
Our needs are only one factor. We need to consider the overall needs of the RTEMS community. That being said, I'll be happy to explain some more a little later.

> 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?

Take a look at the links I added to your document proposal:

Specifically:

https://github.com/lttng/lttng-tools/blob/master/doc/live-reading-protocol.txt

I would highly recommended reading the beginning of this document to understand what CTF really is.
http://diamon.org/ctf/#specification

I would also suggest building a barebones C program that can read a CTF stream given a super simple metadata file.Once you understand what CTF is, and how the metadata describes
it, this shouldn't take more than a day or two. That being said, it could take quite a long time for the concepts to make sense.

This program should not parse or read metadata at all, just interpret the stream assuming a fixed metadata file.
I did this exercise, and it was really helpful in intuitively understanding CTF.

lttng-live is a protocol that talks to a trace server over TCP (sometimes called relay daemon), and asks it for trace streams. It sends some messages and gets
some replies from the server, and then starts receiving the trace stream.

Isaac

> 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
>>>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>