GSoC Project | Basic Support for Trace Compass

Ravindra Kumar Meena rmeena840 at gmail.com
Thu May 16 09:09:47 UTC 2019


Hi Guillaume,

Thanks for sharing the valuable approach. I will definitely check them out.

Thanks

On Thu, May 16, 2019, 1:16 AM Guillaume Champagne <
guillaume.champagne at polymtl.ca> wrote:

> Hi Ravindra,
>
> If you look at the dependencies and build process of lttng-tools [1]
> and lttng-modules [2] you'll see that both projects are very tied to
> linux. Lttng stands for linux tracing toolkit next generation after
> all :).
>
> An idea to produce CTF could be to reuse the binary format already
> existing in the Capture Engine and write a CTF metadata file to
> explain the format to the CTF parser. CTF is very flexible and we can
> make it understand a wide range of binary formats. The CTF spec has a
> few examples on that at the end [3]. Trace Compass only cares about
> the event types in the trace and their content, not their actual
> binary representation (they just have to be decodable using the CTF
> metadata file). I had a working prototype for CTF traces in RTEMS here
> [4], but I don't have the metadata file I used at hand.
>
> Feel free to come by the tracecompass or lttng irc channels if you
> have any questions regarding Trace Compass or CTF!
>
> [1] https://github.com/lttng/lttng-tools
> [2] https://github.com/lttng/lttng-modules
> [3] https://diamon.org/ctf/#examples
> [4] https://github.com/gchamp20/rtems/commits/ctf
>
> Guillaume
>
> Ravindra Kumar Meena <rmeena840 at gmail.com> a écrit :
>
> > Hi Sebastian,
> >
> > I was exploring the documentation of LTTng and babeltrace and come to the
> > conclusion that LTTng already produces trace data in CTF format. Since
> > Trace Compass already supports CTF trace data. So, what I am thinking
> that
> > instead of converting trace data to CTF why don't we just directly
> produce
> > trace data in CTF using LTTng.
> >
> > https://lttng.org/docs/v2.10/#doc-tracing-your-own-user-application
> >
> >
> > On Tue, May 14, 2019 at 12:45 PM Sebastian Huber <
> > sebastian.huber at embedded-brains.de> wrote:
> >
> >> On 14/05/2019 08:34, Ravindra Kumar Meena wrote:
> >> > On Tue, May 14, 2019 at 11:24 AM Sebastian Huber
> >> > <sebastian.huber at embedded-brains.de
> >> > <mailto:sebastian.huber at embedded-brains.de>> wrote:
> >> >
> >> >     On 13/05/2019 08:24, Ravindra Kumar Meena wrote:
> >> >     >
> >> >     > *The goal of this week:*
> >> >     >
> >> >     > The goal of phase 1 of my GSoC proposal is to generate the trace
> >> >     > data(LTTng) in Common Trace Format(CTF) from target running
> RTEMS
> >> >     > application. The Event Recording infrastructure lacks the
> >> >     generation
> >> >     > of trace data in Common Trace Format(CTF). I will try to figure
> >> >     out a
> >> >     > convenient method for it.
> >> >
> >> >     Please note that there are at least two options where you can do
> the
> >> >     conversion, you can do the conversion on the target or you can do
> the
> >> >     conversion on the host.
> >> >
> >> >
> >> > In my point of view, the conversion should take place on the host side
> >> > because the host is more powerful. It would reduce the conversion
> time.
> >>
> >> Yes, I would try this a approach first. However, please keep in mind
> >> that RTEMS runs also on 1.5GHz chips with 24 cores. This means the
> >> conversion must be fast also on a modern host computer if you want to
> >> support the high end RTEMS systems.
> >>
> >> --
> >> Sebastian Huber, embedded brains GmbH
> >>
> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> >> Phone   : +49 89 189 47 41-16
> >> Fax     : +49 89 189 47 41-09
> >> E-Mail  : sebastian.huber at embedded-brains.de
> >> PGP     : Public key available on request.
> >>
> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >>
> >>
> >
> > --
> > *Ravindra Kumar Meena*,
> > B. Tech. Computer Science and Engineering,
> > Indian Institute of Technology (Indian School of Mines)
> > <https://www.iitism.ac.in/>, Dhanbad
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190516/ca63897b/attachment.html>


More information about the devel mailing list