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