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.guteku...@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 iguteku...@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 <chr...@rtems.org> >> Sent: 16 March 2016 10:18 >> To: Vivek Kukreja; guteku...@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 <chr...@rtems.org> >>> Sent: 10 March 2016 08:11 >>> To: Vivek Kukreja >>> Cc: guteku...@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@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel >> _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
