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