GSoC Project | Basic Support for Trace Compass
Hi, I have completed the task assigned by Gedare Bloom. I have updated the wiki page https://devel.rtems.org/wiki/GSoC/2019 I have written a blog https://rmeena840.github.io/ which includes two posts. First one is about GSoC introduction and the second post is about setting up the development environment. I would like to work on the project now. https://devel.rtems.org/ticket/3696 *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. Thanks -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
On Tue, May 14, 2019 at 11:24 AM Sebastian Huber < sebastian.hu...@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. > > With CTF you can store arbitrary trace data. We also need CTF data which > is understood by Trace Compass or we have to teach Trace Compass that it > understands our RTEMS-specific CTF data. I am currently reading the documentation of CTF, Babeltrace, and barectf. > > > -- > 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.hu...@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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
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.hu...@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 > > > <mailto:sebastian.hu...@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.hu...@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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
On Wed, May 15, 2019 at 5:27 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 15/05/2019 13:50, Ravindra Kumar Meena wrote: > > Is lttng under a suitable license (I think no) and portable to RTEMS? > I found this at the bottom of LTTng website. https://lttng.org/ " The LTTng Documentation is licensed under CC BY 4.0. LTTng-tools is licensed under LGPLv2.1 and GPLv2. LTTng-UST is licensed under LGPLv2.1, the MIT license and GPLv2. LTTng-modules is licensed under LGPLv2.1, GPLv2 and the MIT license. " I am not sure what type of license is suitable. Does it meet the performance requirements? How do I check that? These are the features of LTTng https://lttng.org/features/ > -- > 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.hu...@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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
Hi Sebastian, Thanks for the clarification. I had one approach in my mind(direct generation of CTF) which seems failed now. Now, how should I convert the trace data into CTF? I looked into the codebase. I think these are the below files that we have to work with. grep -r rtems/record.h --include='*.[ch]' cpukit/include/rtems/confdefs.h:#include cpukit/libtrace/record/record-server.c:#include cpukit/libtrace/record/record-sysinit.c:#include cpukit/libtrace/record/record.c:#include cpukit/libtrace/record/record-userext.c:#include 5/arm-rtems5/xilinx_zynq_a9_qemu/lib/include/rtems/confdefs.h:#include Thanks On Thu, May 16, 2019 at 12:14 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 15/05/2019 18:45, Ravindra Kumar Meena wrote: > > > > On Wed, May 15, 2019 at 5:27 PM Sebastian Huber > > > <mailto:sebastian.hu...@embedded-brains.de>> wrote: > > > > On 15/05/2019 13:50, Ravindra Kumar Meena wrote: > > > > Is lttng under a suitable license (I think no) and portable to RTEMS? > > > > I found this at the bottom of LTTng website. https://lttng.org/ > > > > " The LTTng Documentation is licensed under CC BY 4.0. LTTng-tools is > > licensed under LGPLv2.1 and GPLv2. LTTng-UST is licensed under > > LGPLv2.1, the MIT license and GPLv2. LTTng-modules is licensed under > > LGPLv2.1, GPLv2 and the MIT license. " > > > > I am not sure what type of license is suitable. > > RTEMS requires permissive licenses, e.g. > > https://devel.rtems.org/wiki/Developer/Contributing#LegalRequirements > > I think you suggested to use LTTng-UST: > > https://github.com/lttng/lttng-ust/blob/master/LICENSE > > "LTTng UST (User-Space Tracer) Licensing > Mathieu Desnoyers > December 5, 2012 > > > * LGPLv2.1 > > This library is distributed under the LGPLv2.1 license. It is intended > to allow use of the tracer API from both free and proprietary software. > > * MIT license : > > Public header files, and LTTng filter runtime code are distributed under > the MIT license. See mit-license.txt for details. > > * GPLv2 > > Library test code is distributed under the GPLv2 license, as specified > in the > per-file license. See gpl-2.0.txt for details. A copy of the > perf_event.h Linux kernel installed header file is also licensed under > GPLv2." > > So, the support library is LGPLv2.1, which is not suitable for RTEMS. > > > > > Does it meet the performance requirements? > > > > > > How do I check that? These are the features of LTTng > > https://lttng.org/features/ > > LTTng has several parts, you should be more specific. I guess you mean > the LTTng User Space Tracing (LTTng-UST) library. There are two issues > with it > > 1. it uses LGPLv2.1, and > > 2. it supports currently only the Linux user space. > > I don't think porting it to RTEMS makes sense as a part of this GSoC > project. > > -- > 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.hu...@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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
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.champa...@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 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.hu...@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 > >> > >> > <mailto:sebastian.hu...@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.hu...@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 > > > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
On Thu, May 16, 2019 at 2:54 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 16/05/2019 11:05, Ravindra Kumar Meena wrote: > > The record data format is described in > cpukit/include/rtems/recorddata.h. If you think this documentation is > insufficient, unclear and needs to be improved, then please do this as > part of the project. > I can see there is a fixed set of 512 system reserved and 512 user-defined events. The total size of the record i item is 32 bits out of which 10 bits are allocated to the event and 22 bits are allocated to timestamps. The record item is defined in two formats 32 and 64 bits. > > With the Qemu simulation you set up during the project proposal, you are > able to get a TCP stream of record items from the Qemu target to your > host. You also have an example client which sorts this stream, > determines the timestamps and prints the items. > The stream print function is defined at rtems-tools/misc/record/record-main.c inside function "static void print_item( FILE *f, const client_item *item )". This function prints the TCP stram. > > Your job is now to convert the record item stream into a CTF stream. In order to convert to CTF, we need to know the structure of it. I followed this page https://diamon.org/ctf/. The CTF stream packet has three major parts header, context, concatenated events(header, stream-specific context, event-specific context, payload). *I would like to point out one thing that I recently pulled the rtems-libbsd and tried to build it again. The build fails due to recent commits made in the master branch(after the commits "Update due to API changes").* Thanks > > > -- > 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.hu...@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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
Hi Sebastian,
I followed https://diamon.org/ctf/ and tried to code. I forked the
rtems-tools and made a commit.
https://github.com/rmeena840/rtems-tools/commit/e1917f5afeba051e4e87285eed9e36b2591dc643
Please have a look and let me know if I am going in the right direction.
I would like to ask one thing that at 5.1 of https://diamon.org/ctf/ it is
mentioned that "trace.packet.header" is required. Since, It was not there I
was getting error at:
trace {
/* ... */
packet.header := struct event_packet_header;
};
Is there any need requirement of file or library?
On Mon, May 20, 2019 at 11:23 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 20/05/2019 07:46, Ravindra Kumar Meena wrote:
> > On Thu, May 16, 2019 at 2:54 PM Sebastian Huber
> > > <mailto:sebastian.hu...@embedded-brains.de>> wrote:
> >
> > On 16/05/2019 11:05, Ravindra Kumar Meena wrote:
> >
> > The record data format is described in
> > cpukit/include/rtems/recorddata.h. If you think this documentation is
> > insufficient, unclear and needs to be improved, then please do
> > this as
> > part of the project.
> >
> >
> > I can see there is a fixed set of 512 system reserved and 512
> > user-defined events. The total size of the record i item is 32 bits
> > out of which 10 bits are allocated to the event and 22 bits are
> > allocated to timestamps. The record item is defined in two formats 32
> > and 64 bits.
>
> Yes, the target depends if the data member is 32-bits or 64-bits. The
> reason for this is that we need enough space to store pointers.
>
> >
> > With the Qemu simulation you set up during the project proposal,
> > you are
> > able to get a TCP stream of record items from the Qemu target to your
> > host. You also have an example client which sorts this stream,
> > determines the timestamps and prints the items.
> >
> >
> > The stream print function is defined at
> > rtems-tools/misc/record/record-main.c inside function "static void
> > print_item( FILE *f, const client_item *item )". This function prints
> > the TCP stram.
>
> Yes.
>
> >
> > Your job is now to convert the record item stream into a CTF stream.
> >
> >
> > In order to convert to CTF, we need to know the structure of it. I
> > followed this page https://diamon.org/ctf/. The CTF stream packet has
> > three major parts header, context, concatenated events(header,
> > stream-specific context, event-specific context, payload).
>
> Yes.
>
> >
> > *I would like to point out one thing that I recently pulled the
> > rtems-libbsd and tried to build it again. The build fails due to
> > recent commits made in the master branch(after the commits "Update due
> > to API changes").*
>
> If you update rtems-libbsd, then also update rtems and build the BSP
> again, then build the libbsd.
>
> > *
> > *
> > Thanks
> >
> >
> >
> > --
> > 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.hu...@embedded-brains.de
> > <mailto:sebastian.hu...@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
>
> --
> 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.hu...@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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
On Fri, May 24, 2019 at 4:51 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello Ravindra,
>
> - Am 22. Mai 2019 um 7:40 schrieb Sebastian Huber
> sebastian.hu...@embedded-brains.de:
>
> > On 21/05/2019 20:21, Ravindra Kumar Meena wrote:
> >> Hi Sebastian,
> >>
> >> I followed https://diamon.org/ctf/ and tried to code.
> >
> > Which code did you try?
> >
> > Did you have a look at babeltrace?
> >
> > https://diamon.org/babeltrace/
> >
> > I would start with this if I had to convert an arbitrary format to CTF.
> >
> >> I forked the rtems-tools and made a commit.
> >>
> https://github.com/rmeena840/rtems-tools/commit/e1917f5afeba051e4e87285eed9e36b2591dc643
> >>
> >> Please have a look and let me know if I am going in the right direction.
> >
> > Please don't add this stuff to recorddata.h, use a separate header, e.g.
> > recordctf.h
> >
> >>
> >>
> >> I would like to ask one thing that at 5.1 of https://diamon.org/ctf/
> >> it is mentioned that "trace.packet.header" is required. Since, It was
> >> not there I was getting error at:
> >>
> >> trace {
> >> /* ... */
> >> packet.header := struct event_packet_header;
> >> };
> >>
> >> Is there any need requirement of file or library?
> >
> > Please try to use babeltrace first.
>
> How is your progress in this area?
>
I was going through babeltrace(https://diamon.org/babeltrace/)
documentation. The whole documentation of babeltrace is described in
python. On documentation, I found that It only works with python3.
Do I have to code in python to trace the C/C++ application?
>
> With respect to the conversion to CTF, please keep also in mind that CTF
> is a generic format and we are interested in a particular consumer, which
> is the Trace Compass.
>
Okay
>
> In this ticket I already mentioned to options:
>
> https://devel.rtems.org/ticket/3696
>
> "To tackle problem 3. there are two approaches possible. You can extend
> the Trace Compass to work with the trace data provided by RTEMS as is.
> Alternatively, the RTEMS trace data could be converted to Linux kernel
> trace data (lttng) which Trace Compass already understands."
Okay
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
> > > > Please clone the repository and look at it a bit more closely. > Which repository? I have already cloned the rtems-libbsd. > > > > > Do I have to code in python to trace the C/C++ application? > > No, that would be to slow. > Okay > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
On Mon, May 27, 2019 at 7:51 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 26/05/2019 13:49, Ravindra Kumar Meena wrote:
> > Hi Sebastian, Gedare
> >
> > On Fri, May 24, 2019 at 8:11 PM Gedare Bloom > <mailto:ged...@gwmail.gwu.edu>> wrote:
> >
> >
> >
> > On Fri, May 24, 2019, 8:32 AM Ravindra Kumar Meena
> > mailto:rmeena...@gmail.com>> wrote:
> >
> >
> >
> > >Please clone the repository and look at it a bit more
> closely.
> >
> >
> > >Which repository? I have already cloned the rtems-libbsd.
> >
> > >Get to understand how to use babeltrace. Try some small examples.
> >
> > I tried tracing example given here
> > https://lttng.org/docs/v2.10/#doc-tracing-your-own-user-application.
> > This example generates the CTF data. I have attached all the files in
> > case if you want to try them out. After that, I used babeltrace to
> > read the CTF data and print it in text format. I have also attached
> > the output("babeltrace CTF.png") of the command line.
> >
> > I used "babeltrace ~/lttng-traces/my-user-space-session*" command line
> > to read the CTF data.
>
> >This is good, since you can use the same method to check the CTF data
> you generate from an RTEMS record item stream.
>
Yes. I was trying the lttng-live command just in the hope that I could get
the trace data stream. Then I used the babeltrace command to connect to the
target. It got connected to the target but no data stream were received in
output.
The following babeltrace command were used:
*1. To connect to target.*
babeltrace --input-format=lttng-live net://localhost/host/
169.254.106.131/my-session
*2. To retrieve the trace data.*
babeltrace --input-format=lttng-live net://localhost
I have attached the output for your reference.
>
> --
> 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.hu...@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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
On Tue, May 28, 2019, 10:36 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 27/05/2019 20:24, Ravindra Kumar Meena wrote:
> >
> > On Mon, May 27, 2019 at 7:51 PM Sebastian Huber
> > > <mailto:sebastian.hu...@embedded-brains.de>> wrote:
> >
> > On 26/05/2019 13:49, Ravindra Kumar Meena wrote:
> > > Hi Sebastian, Gedare
> > >
> > > On Fri, May 24, 2019 at 8:11 PM Gedare Bloom
> > mailto:ged...@gwmail.gwu.edu>
> > > <mailto:ged...@gwmail.gwu.edu <mailto:ged...@gwmail.gwu.edu>>>
> > wrote:
> > >
> > >
> > >
> > > On Fri, May 24, 2019, 8:32 AM Ravindra Kumar Meena
> > > mailto:rmeena...@gmail.com>
> > <mailto:rmeena...@gmail.com <mailto:rmeena...@gmail.com>>> wrote:
> > >
> > >
> > >
> > > >Please clone the repository and look at it a bit
> > more closely.
> > >
> > >
> > > >Which repository? I have already cloned the rtems-libbsd.
> > >
> > > >Get to understand how to use babeltrace. Try some small
> > examples.
> > >
> > > I tried tracing example given here
> > >
> > https://lttng.org/docs/v2.10/#doc-tracing-your-own-user-application.
> > > This example generates the CTF data. I have attached all the
> > files in
> > > case if you want to try them out. After that, I used babeltrace to
> > > read the CTF data and print it in text format. I have also attached
> > > the output("babeltrace CTF.png") of the command line.
> > >
> > > I used "babeltrace ~/lttng-traces/my-user-space-session*"
> > command line
> > > to read the CTF data.
> >
> > >This is good, since you can use the same method to check the CTF
> > data
> > you generate from an RTEMS record item stream.
> >
> >
> > Yes. I was trying the lttng-live command just in the hope that I could
> > get the trace data stream. Then I used the babeltrace command to
> > connect to the target. It got connected to the target but no data
> > stream were received in output.
>
> What do you mean with "target"?
>
The target is where application is running. The telnet with IP address
command that we used for connecting to the target.
>
> --
> 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.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
On Tue, May 28, 2019 at 12:51 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > > In case the application is an RTEMS application running inside Qemu, > then of course babletrace will have problems to understand the record > item steam since it is not in CTF format. We have the following situation: > > [ RTEMS application with event recording running on Qemu ] > <- TCP stream of record items -> > [ babeltrace ] > > What we probably need is something like this: > > [ RTEMS application with event recording running on Qemu ] > <- TCP stream of record items -> > [ custom converter program ] > <- TCP stream of CTF data -> > [ babeltrace ] or [ Trace Compass ] > Okay. Thanks for the clarification. The small example that I showed you where CTF data was printed in text format using babeltrace. It requires LTTng-UST. We can't use it because you had already mentioned that there is a license problem with it. With LTTng-UST I was able to define tracepoint provider package and tracepoints in the program. You can follow this link in case if you wanna have a look at it again. https://lttng.org/docs/v2.10/#doc-tracing-your-own-user-application Without the help of LTTng-UST how we will be able to define tracepoints in the program? -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
Hi Sebastian, I talked to babeltrace community and come to the conclusion that current stable version 1.5.6 of babeltrace is not capable of converting live trace stream data into CTF. This feature is currently in development and will be released in babeltrace 2.0. If we are able to store the current traces in the disk then I think we convert it to CTF later. Thanks On Tue, May 28, 2019 at 1:49 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 28/05/2019 10:14, Ravindra Kumar Meena wrote: > > On Tue, May 28, 2019 at 12:51 PM Sebastian Huber > > > <mailto:sebastian.hu...@embedded-brains.de>> wrote: > > > > > > In case the application is an RTEMS application running inside Qemu, > > then of course babletrace will have problems to understand the record > > item steam since it is not in CTF format. We have the following > > situation: > > > > [ RTEMS application with event recording running on Qemu ] > > <- TCP stream of record items -> > > [ babeltrace ] > > > > What we probably need is something like this: > > > > [ RTEMS application with event recording running on Qemu ] > > <- TCP stream of record items -> > > [ custom converter program ] > > <- TCP stream of CTF data -> > > [ babeltrace ] or [ Trace Compass ] > > > > > > Okay. Thanks for the clarification. The small example that I showed > > you where CTF data was printed in text format using babeltrace. It > > requires LTTng-UST. We can't use it because you had already mentioned > > that there is a license problem with it. > > > > With LTTng-UST I was able to define tracepoint provider package and > > tracepoints in the program. You can follow this link in case if you > > wanna have a look at it again. > > https://lttng.org/docs/v2.10/#doc-tracing-your-own-user-application > > > > Without the help of LTTng-UST how we will be able to define > > tracepoints in the program? > > Defining tracepoints in RTEMS applications is currently outside the > scope of this project. You should really focus on the things mentioned > in ticket: > > https://devel.rtems.org/ticket/3696 > > The primary goal is to convert the record item stream into something which > Trace Compass understands. As a first step, you can simplify this to: > convert the record item stream into a CTF stream which babeltrace > understands. > > -- > 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.hu...@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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
Hi Sebastian, I am in regular touch with Babeltrace community to figure out the solution for conversion of trace data into CTF. I came to the conclusion that current version 1.5.6 of Babeltrace does not have a feature to convert live trace stream into CTF(we already had a discussion about it). However, this feature is currently available in Babeltrace 2.0(master branch) but it is currently in pre-stage. The approach they shared is that after post-processing phase to convert traces from some existing format to CTF we have to create a Babeltrace 2 source plugin which reads our trace format into the Babeltrace 2 intermediate representation by using the APIs exposed to plugins by Babeltrace 2. Babeltrace 2 has a generic CTF sink which can serialize the resulting trace intermediate representation into CTF. The conversation I had between them in May is: https://lists.lttng.org/pipermail/lttng-dev/2019-May/028944.html and this months conversation is: https://lists.lttng.org/pipermail/lttng-dev/2019-June/029022.html Please have a look at the above thread. The community is very helpful they have even shared a decoder(source plugin) example(you can see them in the thread itself) which is necessary for whatever is produced as trace output to convert into CTF. I will have a look at it. I also came to know that Trace Compass does not support live traces. It is made for post-mortem analyses, so it works only on complete trace. They briefly supported live traces a few years back, but that made the code much more complicated, so this support was dropped. TraceCompass is not made for trace monitoring! You can view the whole conversation here(I did this during application period): https://lists.lttng.org/pipermail/lttng-dev/2019-March/028677.html So, in my point of view, we should stick with the post-processing method. We should store the traces in the disk and then convert it to CTF. Thanks -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
CTF example
Hi Gedare, This is with reference to meeting we recently conducted on freenode. You had suggested that you have working examples on CTF. Can you please share them all here? If possible, please share anything other related to decoder(source plugin) which would help in converting current trace data generated from Event Recording infrastructure to CTF. It would help me in conversion of current trace data to CTF. Thanks ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
On Wed, Jun 5, 2019 at 11:03 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 04/06/2019 19:26, Ravindra Kumar Meena wrote: > > Hi Sebastian, > > > > I am in regular touch with Babeltrace community to figure out the > > solution for conversion of trace data into CTF. I came to the > > conclusion that current version 1.5.6 of Babeltrace does not have a > > feature to convert live trace stream into CTF(we already had a > > discussion about it). However, this feature is currently available in > > Babeltrace 2.0(master branch) but it is currently in pre-stage. > > > > The approach they shared is that after post-processing phase to > > convert traces from some existing format to CTF we have to create a > > Babeltrace 2 source plugin which reads our trace format into the > > Babeltrace 2 intermediate representation by using the APIs exposed to > > plugins by Babeltrace 2. Babeltrace 2 has a generic CTF sink which can > > serialize the resulting trace intermediate representation into CTF. > > > > The conversation I had between them in May is: > > https://lists.lttng.org/pipermail/lttng-dev/2019-May/028944.html > > > > and this months conversation is: > > https://lists.lttng.org/pipermail/lttng-dev/2019-June/029022.html > > > > Please have a look at the above thread. The community is very helpful > > they have even shared a decoder(source plugin) example(you can see > > them in the thread itself) which is necessary for whatever is produced > > as trace output to convert into CTF. I will have a look at it. > > Thanks for the summary. The Babeltrace 2 source plugin look like the way > to go. > Okay. I will try the decoder(source plugin) example. > > > > > I also came to know that Trace Compass does not support live > > traces. It is made for post-mortem analyses, so it works only on > > complete trace. They briefly supported live traces a few years back, > > but that made the code much more complicated, so this support was > > dropped. TraceCompass is not made for trace monitoring! > > Hm, interesting. This limitation is not really visible from the > marketing sites. > Yes. The community itself confirmed it. > > > > > You can view the whole conversation here(I did this during application > > period): > > https://lists.lttng.org/pipermail/lttng-dev/2019-March/028677.html > > In the e-mail a session rotation is mentioned. This doesn't sound that > bad. At the moment this is not really important. We need the basics first. > Okay > > > > > So, in my point of view, we should stick with the post-processing > > method. We should store the traces in the disk and then convert it to > CTF. > > I would try to concentrate on a Babeltrace 2 source plugin. If it works > we should try to upstream it to: > > https://github.com/efficios/babeltrace/tree/master/plugins Okay. sure :) > > > Alternatively, you can try to write the converter using support from > barectf. > Okay. I am currently reading its documentation. I will try the examples first. > > -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] adding basic support for trace compass
Hi Sebastian, Chris I created the Image online on https://www.draw.io/. Is it necessary to use Ditaa and PlantUML? Thanks On Thu, Jun 6, 2019 at 4:13 PM Chris Johns wrote: > On 6/6/19 8:03 pm, Sebastian Huber wrote: > > Hello Chris, > > > > On 06/06/2019 11:54, Ravindra Meena wrote: > >> create mode 100644 images/user/event-recording-trace.png > > > > what is the desired way to include new images in the documentation? > Should we > > try to use PlantUML if possible? > > > > https://git.rtems.org/rtems-docs/tree/README.txt#n45 ? :) > > Ditaa and PlantUML can be used. I think they are pretty good and let us > create > reasonable images quickly and in an open way. > > There are real examples in the User manual. You can see the source here > https://git.rtems.org/rtems-docs/tree/images/user. > > I cover installing the tools on FreeBSD and Joel has added CentOS. > > I cannot remember what happens with git when regenerating the images. I > suggest > only adding the ones you create and add them. We add the .png files to > avoid > everyone needing to install the tools to generate them. > > Chris > -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] adding basic support for trace compass
Hi Sebastian, Chris I have sent the new patch on devel. This time I used PlantUML. I looked at other PlantUML files where the copyright thing was added. I haven't added the copyright thing. Thanks On Thu, Jun 6, 2019 at 4:43 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 06/06/2019 13:09, Ravindra Kumar Meena wrote: > > Hi Sebastian, Chris > > > > I created the Image online on https://www.draw.io/. Is it necessary to > > use Ditaa and PlantUML? > > Yes, this makes it easier to change the image later. > > -- > 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.hu...@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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: CTF example
> > My examples won't be helpful after all. I have some notes and scripts > to convert from CTF to another format (PROV-DM), and I also have some > examples using barectf to generate CTF traces. Let me know if you end > up needing anything like that. > Okay. Please share the barectf examples. Thanks -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Basic Support for Trace Compass
I have sent the new patch with the changes pointed out. Thanks On Sat, Jun 8, 2019 at 6:48 AM Chris Johns wrote: > On 8/6/19 3:05 am, Gedare Bloom wrote:> We require that our GSoC Students > keep > their contributions visible on > > their personal GitHub. I recommend that Ravindra stage the work on > > personal GitHub, and post here for review by the community. Merge from > > personal GitHub to git.rtems.org when sufficiently mature for master. > > Work should continue on the personal GitHub, submitting to ML and > > merging to master as development proceeds. > > Thank you for clarifying this. > > Chris > -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
Hi Sebastian, I will compile the things that we have done so far. This will help to keep track the progress of the project. Progress so far: 1. We successfully tried the babeltrace example which reads CTF data and prints in text format. https://lists.rtems.org/pipermail/devel/2019-May/025921.html 2. We Figured out that current stable version 1.5.6 of Babeltrace does not have a feature to convert live traces stream into CTF. This feature is currently under development and is available in the master branch of Babeltrace 2.0 but it is in pre-stage. 3. We Figured out that Trace Compass does not support live monitoring. Plan for the week: 1. Update the event recording documentation(sent the patches) 2. Build a custom converter that can transform TCP streams and files with record items into CTF. For 2nd point of the plan, we have to write the decoder(source plugin). This would involve understanding the current rtems trace format and codebase. I will also try out the decoder(source plugin) example shared by the babeltrace community. Thanks On Thu, Jun 6, 2019 at 2:42 PM Ravindra Kumar Meena wrote: > > > On Wed, Jun 5, 2019 at 11:03 AM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> On 04/06/2019 19:26, Ravindra Kumar Meena wrote: >> > Hi Sebastian, >> > >> > I am in regular touch with Babeltrace community to figure out the >> > solution for conversion of trace data into CTF. I came to the >> > conclusion that current version 1.5.6 of Babeltrace does not have a >> > feature to convert live trace stream into CTF(we already had a >> > discussion about it). However, this feature is currently available in >> > Babeltrace 2.0(master branch) but it is currently in pre-stage. >> > >> > The approach they shared is that after post-processing phase to >> > convert traces from some existing format to CTF we have to create a >> > Babeltrace 2 source plugin which reads our trace format into the >> > Babeltrace 2 intermediate representation by using the APIs exposed to >> > plugins by Babeltrace 2. Babeltrace 2 has a generic CTF sink which can >> > serialize the resulting trace intermediate representation into CTF. >> > >> > The conversation I had between them in May is: >> > https://lists.lttng.org/pipermail/lttng-dev/2019-May/028944.html >> > >> > and this months conversation is: >> > https://lists.lttng.org/pipermail/lttng-dev/2019-June/029022.html >> > >> > Please have a look at the above thread. The community is very helpful >> > they have even shared a decoder(source plugin) example(you can see >> > them in the thread itself) which is necessary for whatever is produced >> > as trace output to convert into CTF. I will have a look at it. >> >> Thanks for the summary. The Babeltrace 2 source plugin look like the way >> to go. >> > Okay. I will try the decoder(source plugin) example. > >> >> > >> > I also came to know that Trace Compass does not support live >> > traces. It is made for post-mortem analyses, so it works only on >> > complete trace. They briefly supported live traces a few years back, >> > but that made the code much more complicated, so this support was >> > dropped. TraceCompass is not made for trace monitoring! >> >> Hm, interesting. This limitation is not really visible from the >> marketing sites. >> > Yes. The community itself confirmed it. > >> >> > >> > You can view the whole conversation here(I did this during application >> > period): >> > https://lists.lttng.org/pipermail/lttng-dev/2019-March/028677.html >> >> In the e-mail a session rotation is mentioned. This doesn't sound that >> bad. At the moment this is not really important. We need the basics first. >> > Okay > >> >> > >> > So, in my point of view, we should stick with the post-processing >> > method. We should store the traces in the disk and then convert it to >> CTF. >> >> I would try to concentrate on a Babeltrace 2 source plugin. If it works >> we should try to upstream it to: >> >> https://github.com/efficios/babeltrace/tree/master/plugins > > Okay. sure :) > >> >> >> Alternatively, you can try to write the converter using support from >> barectf. >> > Okay. I am currently reading its documentation. I will try the examples > first. > >> >> > > -- > *Ravindra Kumar Meena*, > B. Tech. Computer Science and Engineering, > Indian Institute of Technology (Indian School of Mines) > <https://www.iitism.ac.in/>, Dhanbad > -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Basic Support for Trace Compass
> > you can highlight that this is the second version of a patch with the > "git format-patch -v2" command line option. > Okay. Thanks > > > +++ b/images/user/event-recording-trace.puml > > @@ -0,0 +1,12 @@ > > +@startuml > > + > > +rectangle Host > > +rectangle "Target/QEMU Target" as target > > The information presented here should be abstract. Details how a > particular board or simulator is set up belong to other sections, e.g. > the BSP documentation. > > +rectangle "Trace Compass" as tracecompass > > +rectangle "Babeltrace" as babeltrace > > +Host --> target : Connecting > > +target --> Host : RTEMS Trace Data > > +Host --> tracecompass : CTF > > +Host --> babeltrace : CTF > > + > > +@enduml > > \ No newline at end of file > > When Git complains a newline is missing at the end of the file, then > please fix this. > Okay > > > diff --git a/user/tracing/eventrecording.rst > b/user/tracing/eventrecording.rst > > index d799774..09dc68b 100644 > > --- a/user/tracing/eventrecording.rst > > +++ b/user/tracing/eventrecording.rst > > @@ -6,7 +6,7 @@ > > .. _EventRecording: > > > > Event Recording > > -=== > > +*** > > > > The `event recording` support focuses on the recording of high > frequency > > events such as > > @@ -56,3 +56,48 @@ started by :c:func:`rtems_record_start_server` via a > TCP connection. > > > > On the host computer you may use the command line tool > :file:`rtems-record` to > > get recorded events from the record server running on the target > system. > > + > > +.. _tracecompass: > > + > > +Trace Compass > > += > > + > > +`Trace Compass <https://www.eclipse.org/tracecompass/>`_ is a tool to > analyse > > +and display trace data graphically. Trace data can be gathered from > RTEMS > > +applications via various means, for example: > > + > > +- :ref:`RTEMS Trace Linker ` > > +- :ref:`RTEMS Capture Engine ` > > +- :ref:`RTEMS Event Recording ` > > Currently the plan is to support only the trace data generated by the > event recording. This should be stated here. The user needs a clear > information what is supported. Mentioning too much stuff is just confusing. > Okay > > +Step 3: The trace data received at host from QEMU target is converted > into CTF. > > +Since, Babeltrace and Trace Compass are two compatible software which > can read > > +and write CTF. The converted CTF ca be passed to any of these softwares. > > + > > +.. figure:: ../../images/user/event-recording-trace.png > > + :align: center > > + :width: 75% > > \ No newline at end of file > > > > A worked out Qemu example should move to another section. > Are you talking about the current trace stream which is generated by QEMU target? > > -- > 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.hu...@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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Basic Support for Trace Compass
> > Yes, it would be good to have a worked out example, however, the general > description should be independent of this. > The trace stream received on the host was only possible after applying the two patches in the root directory of rtems-libbsd and rtems-tools. I mean it is not from the master branch of these two repositories. These patches are not the production side. Is it good to talk about patches here? -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Basic Support for Trace Compass
> > These patches are not the production side. Is it good to talk about > > patches here? > > Just use your GSoC branches as a reference. In the end it should work > with the upstream master branches as is without external patches. > > Okay I have added the event recording example and made a push on forked repository https://github.com/rmeena840/rtems-docs/commit/68e2239548dac48f533572152a5c8033ff2122b6 Please have a look. The GitHub has a comment feature too. Please let me if there any changes needed. Thanks -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
> > With "rtems trace format" I guess you mean the format used by the Event > Recording. Could you please elaborate this a bit more what you mean with > understanding. The format is very simple. It is just a timestamp, an > event number and some event specific data. > > Getting timestamps in CLOCK_MONOTONIC nanosecond values is a bit tricky, > however, this is already handled by the client: > > > https://github.com/rmeena840/rtems-tools/commit/0a279786b73197973dc8a5a5f7818a7669714216 > > Did you already work on a TSDL description of the format? > Sorry. I don't know what TSDL is? > > > -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] CTF TSDL
Hi Sebastian, I have added comments on the TSDL code. I have sent the new patch. Please have a look. Thanks On Fri, Jun 14, 2019 at 4:57 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello Ravindra, > > could you please add some comments which explain the magic numbers, e.g. > 1421703448 and the relationship to the raw event recording items > (rtems_record_item) and data which is already somehow converted by the > client. > > -- > 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.hu...@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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
GSoC Project | Basic Support for Trace Compass
Hi, Here is the work summary of 13th and 14th June. *13th June:* 1. I sent a patch for RTEMS trace generation example and made a push on GitHub forked repository also. https://github.com/rmeena840/rtems-docs/commit/68e2239548dac48f533572152a5c8033ff2122b6 2. I set up the babeltrace 2.0 master branch as it has the decoder(source plugin) examples shared by babeltrace community. https://github.com/efficios/babeltrace These are the links they shared with me: [1] http://git.efficios.com/?p=babeltrace.git;a=tree;f=plugins/text/dmesg;h=a45918aaf266dac29db6f7a0e4d08ffdb056131a [2] http://git.efficios.com/?p=babeltrace.git;a=tree;f=plugins/ctf/fs-sink;h=b96b435706cac0ed50cb64918603172b67afc424 As babeltrace 2.0 master branch is under progress. They have not updated their documentation. I was not able to run the examples. I raised a query asking how I can use the examples? I haven't received a reply yet. *14th June:* I tried to write TSDL description by following https://diamon.org/ctf/. Here is the patch I sent https://lists.rtems.org/pipermail/devel/2019-June/026166.html I explored the examples/blogs shared by Sebastian. https://lttng.org/blog/2014/11/25/tracing-bare-metal-systems/ I explored the metadata file of Trace Compass examples https://github.com/tuxology/tracevizlab This metadata is quite similar to metadata I wrote https://lists.rtems.org/pipermail/devel/2019-June/026166.html *Plan for the week:* I will improve the metadata I wrote. https://lists.rtems.org/pipermail/devel/2019-June/026166.html I will explore bartectf tracing example https://github.com/efficios/epiphany-examples/tree/barectf-tracing/apps/barectf-tracing This example is similar to the objective of this GSoC project. The targets generates CTF data and send it back to the host. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] Comment added
On Mon, Jun 17, 2019 at 1:45 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 16/06/2019 20:13, Ravindra Meena wrote:
> > ---
> > misc/CTF/record-ctf.ref | 55
> +
> > 1 file changed, 37 insertions(+), 18 deletions(-)
> >
> > diff --git a/misc/CTF/record-ctf.ref b/misc/CTF/record-ctf.ref
> > index a27757c..bdb9648 100644
> > --- a/misc/CTF/record-ctf.ref
> > +++ b/misc/CTF/record-ctf.ref
> [...]
> > clock {
> > -name = ctf_clock;
> > -freq = 1000;
> > -offset_s = 1421703448;
> > +name = ctf_clock; /* name of montonic clock */
> > +freq = 1000; /* frequency, in HZ */
>
> Why 1000Hz?
>
The freq field is the initial frequency of the clock, in Hz. If the freq
field is not present, the frequency is assumed to be 10 (providing
clock increment of 1 ns). I set to 1000HZ just for getting started.
>
> > +offset_s = 1421703448;
>
> What is this for an offset?
>
This offset is a difference between the beginning of clock and the actual
start of the clock. The event will be recorded just after the offset.
>
> > };
> >
> > +/*
> > + * A reference to the clock added within an integer type
> > + */
> > +
> > typealias integer {
> > size = 64;
> > map = clock.ctf_clock.value;
> > } := ctf_clock_int_t;
>
> Why does this start with "ctf_"?
>
ctf_clock is the name of clock struct I created just above this. It is a
reference to the clock name.
>
> >
> > +/*
> > + * Trace stream packet having header and context.
> > + *
> > + * @param event.header includes id(unique identifier of stream) and
> timestamp.
> > + * @param packet.context includes clock timestamp, cpu id, event and
> event data.
> > + */
> > +
> > stream {
> > id = 0;
> > +event.header := struct {
> > +uint32_t id;
>
> What is this for an id?
>
It is a unique identifier for stream header. There will be many streams so
in order to identify the streams I have set the id here.
>
> > +ctf_clock_int_t timestamp;
>
> Timestamp of what?
>
It is the timestamp of the stream header. It is different from event
header. The event heder can have a beginning and ending timestamp.
>
> > +};
> > packet.context := struct {
> > ctf_clock_int_t timestamp;
> > uint32_t cpu;
> > uint32_t event;
> > uint64_t data;
> > };
> > -event.header := struct {
> > -uint32_t id;
> > -ctf_clock_int_t timestamp;
> > -};
> > };
> >
> > event {
> > -id = 0;
> > -name = "ctf_event";
> > -stream_id = 0;
> > +id = 0; /* event id
> > +name = "ctf_event"; /* event name */
> > + stream_id = 0; /* signifies stream id which event is supposed to
> concat with events */
> > fields := struct {
> > -uint32_t a;
> > -uint16_t b;
> > -string c;
> > +uint32_t a; /*event 1*/
> > +uint16_t b; /*event 2*/
> > +string c; /*event 3*/
>
> What are events 1, 2, 3?
>
I have added this event just for getting started. I thought it would be
better to get it reviewed this much TSDL code.
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] Comment added
> > > misc/CTF/record-ctf.ref | 55 > + > > We should avoid uppercase or mix case in file names unless they are > existing or > in imported code. We have some hosts that are case insensitive and our > experience over the years is this can cause problems. :) > Okay. I didn't know that. :) > > Is this file for the rtems-tools repo? Yes > If it is not please ignore the following. > > I wonder if there should be a top level trace directory to gather all the > trace > pieces in one place. I think trace is important enough to have this > status. So > this file could be ... > > trace/config/ctf/record-ctf.ref > > or > > trace/config/record-ctf.ref > It's metadata file for TSDL description. I will rename it to "metadata" > > ? This is only an example as I am not really sure what role this file > plays. > > Notes: > > 1) I have found in other parts of rtems-tools.git having the config > directory of > files separated from the other sources makes installing into the shared > tree > simpler. > > 2) The tools currently in rtems-tools.git can be run with the same command > line > options from a built repo with an absolute path or when installed under a > prefix. This is something to consider when referencing configuration files. > > Okay, Chris. Thanks for the review. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
> > In which file format this the attached file? I have problems to read it > with a text editor. > I used gedit to open the file. The editor will take little time to load the file and will show encoding problem but still, you can view the file content with gedit. I used "gedit metadata" command to open the file. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
> > > I used gedit to open the file. The editor will take little time to load > > the file and will show encoding problem but still, you can view the file > > content with gedit. > > > > I used "gedit metadata" command to open the file. > > What is the SHA512 checksum of the file you can edit? > > 9556e2f193ed6075ac5f7642c4d83b9a60dfe80bdb2952b2a43675c49dbad00620c7c673982e79a0a03801ea83261b56e5200456ba0751222d4a28e32e34870c -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
> > > What is the SHA512 checksum of the file you can edit? > > > > > 9556e2f193ed6075ac5f7642c4d83b9a60dfe80bdb2952b2a43675c49dbad00620c7c673982e79a0a03801ea83261b56e5200456ba0751222d4a28e32e34870c > > > Ok, I received the same file. kwrite complains that the file contains > invalid UTF-8 sequences. > Okay > > Is this the TSDL description of a Linux kernel trace which can be > consumed by Trace Compass? > Yes. Alternatively, you can download the file [1]. After extracting [1] you will find many metadata files. I sent you the metadata file residing in "101-trace-navigation-in-tracecompass" folder. [1] https://github.com/tuxology/tracevizlab/blob/master/labs/TraceCompassTutorialTraces.tgz -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
17th June work Summary: I sent a patch containing commented code. I had a discussion about metadata file with Sebastian. Raised a query on lttng asking about the file format of metadata. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
> > > It seems the metadata files are somehow packetized. They contain plain > text mixed in with binary data. > > Could you please investigate which file format is used for the metadata > files (e.g. ask on a lttng mailing list)? > I raised a query on lltng for the same. The community is very active. This is what they said: https://lists.lttng.org/pipermail/lttng-dev/2019-June/029056.html Please have a look -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
Hi, About a week ago I raised a query on decoder(source plugin) examples shared by them. They suggested that if we plan to use Babeltrace 2 plugin system, the metadata file will be generated based on the trace representation given by the source plugin. https://lists.lttng.org/pipermail/lttng-dev/2019-June/029057.html Please have a look -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
> > > It seems the metadata files are somehow packetized. They contain > plain > > text mixed in with binary data. > > > > Could you please investigate which file format is used for the > metadata > > files (e.g. ask on a lttng mailing list)? > > > > I raised a query on lltng for the same. The community is very active. > > This is what they said: > > https://lists.lttng.org/pipermail/lttng-dev/2019-June/029056.html > > > > Please have a look > > Did the answers help you to understand how the metadata is generated? > I didn't understand much. [1] [2] [3] are the same the thing I was following to write the metadata file. I had a look at [4] and [5] code. It appears to me that metadata is generated is directly from the code. [1] https://diamon.org/ctf/#spec7 [2] https://diamon.org/ctf/#spec7.4 [3] https://diamon.org/ctf/#specC [4] https://github.com/efficios/barectf/blob/a3ebf5855c025a86ebc2d62cbda1338461e84c5a/barectf/tsdl182gen.py [5] https://github.com/lttng/lttng-tools/blob/c8e0c5f5d94fb574f4e5d7518f0f8e6f984dfe3d/src/bin/lttng-sessiond/ust-metadata.c -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
> > > About a week ago I raised a query on decoder(source plugin) examples > > shared by them. > > > > They suggested that if we plan to use Babeltrace 2 plugin system, the > > metadata file > > will be generated based on the trace representation given by the source > > plugin. > > > > https://lists.lttng.org/pipermail/lttng-dev/2019-June/029057.html > > > > Please have a look > > Yes, this is why I asked about a TSDL description last week: > > https://lists.rtems.org/pipermail/devel/2019-June/026101.html > > Creating the metadata is one of the first actions a plugin must do > Okay. I sent you one metadata file which had 1160 events. So should I add the rtems 512 events in metadata? The problem I am facing here is how to relate the metadata file with rtems event record item? -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
Hi I found the metadata packet image online. However, packet information is also given on https://diamon.org/ctf/ but I find it more clear. I have attached the file. Please have a look at it. > -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
>
> > Creating the metadata is one of the first actions a plugin must do
> >
> > Okay.
> >
> > I sent you one metadata file which had 1160 events. So should I add the
> > rtems 512 events in metadata?
>
> At the moment a detailed description of individual events is not
> necessary. We have to get the basics in place first. So for now an 10
> bit event number is enough.
>
in recorddata.h I can see that out of 32 bits 10 bits are reserved for
event and 22 bits are reserved for time of the event.
With event number you mean 10 bits reserved for events?
>
> >
> > The problem I am facing here is how to relate the metadata file with
> > rtems event record item?
>
> This depends on what you want to do. It seems the babeltrace plugin is a
> bit too complex to write at the moment. Maybe we should start with
> something simpler.
>
> The record client in your rtems-tools repository does the following:
>
> target --> TCP stream with struct rtems_record_items -> client ->
> conversion -> human readable text
>
Okay
>
> We should turn this into:
>
> target --> TCP stream with struct rtems_record_items -> client ->
> conversion ->
Okay up to this everything is working fine .
> CTF (metadata + event stream) -> files -> babeltrace ->
> human readable text
>
We have to deal with this.
>
> So the first thing we have to figure out is how babeltrace reads an
> arbitrary CTF session (metadata + event stream).
> The next thing is to look at and modify print_item() in
> misc/record/record-main.c. In this function you get one client_item
> after another.
>
> typedef struct client_item {
>union {
> SLIST_ENTRY( client_item ) free_node;
> RB_ENTRY( client_item )active_node;
>};
>uint64_t ns;
>uint32_t cpu;
>rtems_record_event event;
>uint64_t data;
>uint64_t counter;
> } client_item;
>
> We are only interested in ns, cpu, event and data. So just convert this to
>
> typedef struct {
>uint64_t ns;
>uint32_t cpu;
>rtems_record_event event;
>uint64_t data;
> } ctf_event;
>
If we are removing SLIST_ENTRY( client_item ) and RB_ENTRY( client_item )
then we will also have to remove it's SLIST_HEAD(), RB_HEAD() etc.
>
> and append this item into a file (the event stream file). For this
> ctf_event you need a TSDL metadata. Save this metadata file.
>
I have tried babeltrace example [1]. The babeltrace was using generated
metadata file.
We can also try barectf. It just needs yaml file which generated c code.
>
> Import the metadata and event stream in babeltrace and let it print a
> human readable form.
>
> Does this look like something you can do?
>
Okay. I will try. This was very much helpful but I think babeltrace will
definitely need generated metadata file.
[1] https://lists.rtems.org/pipermail/devel/2019-May/025921.html
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
*18th June:* Forwarded the response received from babeltrace about the metadata file format. Added three more posts on [1] as part of GSoC project. Tried barectf example and found that metadata file can be generated with the help of barectf. Barectf just needs yaml file and it can directly generate the metadata file. Discussed about metadata file. [1] https://rmeena840.github.io/ -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
>
> > > Creating the metadata is one of the first actions a plugin
> > must do
> > >
> > > Okay.
> > >
> > > I sent you one metadata file which had 1160 events. So should I
> > add the
> > > rtems 512 events in metadata?
> >
> > At the moment a detailed description of individual events is not
> > necessary. We have to get the basics in place first. So for now an 10
> > bit event number is enough.
> >
> > in recorddata.h I can see that out of 32 bits 10 bits are reserved for
> > event and 22 bits are reserved for time of the event.
> > With event number you mean 10 bits reserved for events?
>
> Yes.
>
Okay.
>
> >
> >
> > >
> > > The problem I am facing here is how to relate the metadata file
> with
> > > rtems event record item?
> >
> > This depends on what you want to do. It seems the babeltrace plugin
> > is a
> > bit too complex to write at the moment. Maybe we should start with
> > something simpler.
> >
> > The record client in your rtems-tools repository does the following:
> >
> > target --> TCP stream with struct rtems_record_items -> client ->
> > conversion -> human readable text
> >
> > Okay
> >
> >
> > We should turn this into:
> >
> > target --> TCP stream with struct rtems_record_items -> client ->
> > conversion ->
> >
> > Okay up to this everything is working fine .
> >
> > CTF (metadata + event stream) -> files -> babeltrace ->
> > human readable text
> >
> > We have to deal with this.
> >
> >
> > So the first thing we have to figure out is how babeltrace reads an
> > arbitrary CTF session (metadata + event stream).
> >
> >
> > The next thing is to look at and modify print_item() in
> > misc/record/record-main.c. In this function you get one client_item
> > after another.
> >
> > typedef struct client_item {
> > union {
> > SLIST_ENTRY( client_item ) free_node;
> > RB_ENTRY( client_item )active_node;
> > };
> > uint64_t ns;
> > uint32_t cpu;
> > rtems_record_event event;
> > uint64_t data;
> > uint64_t counter;
> > } client_item;
> >
> > We are only interested in ns, cpu, event and data. So just convert
> > this to
> >
> > typedef struct {
> > uint64_t ns;
> > uint32_t cpu;
> > rtems_record_event event;
> > uint64_t data;
> > } ctf_event;
> >
> > If we are removing SLIST_ENTRY( client_item ) and RB_ENTRY( client_item
> > ) then we will also have to remove it's SLIST_HEAD(), RB_HEAD() etc.
>
> What do you mean with "remove it's SLIST_HEAD(), RB_HEAD() etc."?
>
Okay. I saw it wrong. I thought these are dependent on SLIST_ENTRY(
client_item ) and RB_ENTRY( client_item).
>
> In print_item() you get a client_item which contains also implementation
> details of the client (the nodes and the counter). These members are not
> relevant for the converted event stream.
>
Okay
>
> >
> >
> > and append this item into a file (the event stream file). For this
> > ctf_event you need a TSDL metadata. Save this metadata file.
> >
> > I have tried babeltrace example [1]. The babeltrace was using generated
> > metadata file.
> > We can also try barectf. It just needs yaml file which generated c code.
>
> Why do we need additional tools here? Is it not sufficient to generate
> the metadata in plain text format and save the event stream as binary data?
>
I was just trying barectf yesterday. I was able to generate metadata file
with it. YAML file is very easy to write. I used "barectf config.yaml -m
ctf" command.
>
> >
> >
> > Import the metadata and event stream in babeltrace and let it print a
> > human readable form.
> >
> > Does this look like something you can do?
> >
> > Okay. I will try. This was very much helpful but I think babeltrace will
> > definitely need generated metadata file.
> >
> > [1] https://lists.rtems.org/pipermail/devel/2019-May/025921.html
>
> The metadata is a part of CTF, so everyone consuming CTF data needs it.
>
Okay
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
Hi, I asked the babeltrace community about the difference between binary packetized and the simple text metadata file. They say both will work the way. Here is the response: https://lists.lttng.org/pipermail/lttng-dev/2019-June/029059.html -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
>
>
> Just to make sure we have a common understanding of the task. Could you
> please explain the task with your ideas to implement it in your own works?
>
Sure.
As of now, we have to deal with 10-bit event number. This is the same event
recording infrastructure is using.
We have to turn record-client into something like this:
target --> TCP stream with struct rtems_record_items -> client ->
conversion -> CTF (metadata + event stream) -> files -> babeltrace ->
human readable text
Here in CTF (metadata + event stream), is event stream the same Event
Recording infrastructure producing or is it a new event stream we have to
make target to produce?
I am not sure how we have to store the event stream in a file? I once used
nc(1) to store in the disk but the stored file didn't seem useful for work.
The first objective is to create metadata and figure out how babeltrace
reads an arbitrary CTF session(CTF+event stream).
Then next modify print_item() in misc/record/record-main.c and change
client_item to:
typedef struct {
uint64_t ns;
uint32_t cpu;
rtems_record_event event;
uint64_t data;
} ctf_event;
This is just one event. We have to append this item one by one in a file.
This file will be called event stream file.
If everything goes well then the next step would be just importing the
metadata and event stream in babeltrace and print its human-readable form.
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
*19th June work summary:* Forwarded the response received from babeltrace community. Tried to improve the metadata and sent the patch for the same for review. Attended the meeting on Freenode. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
Hi Sebastian, We wanted to figure out how babeltrace reads the CTF session(CTF+event stream). I asked the same to the community. They suggested that babeltrace traverses the tree and look for files named "metadata". All files at the same depth of a metadata file are considered CTF streams. Here is the response: https://lists.lttng.org/pipermail/lttng-dev/2019-June/029062.html They have explained it with example Have a look Thanks -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
Hi, I tried babeltrace to test the metadata file I wrote. Babeltrace was reading the metadata file without any error or warning. I intentionally made some error in metadata file and babeltrace was printing error in metadata file. This means that metadata file that we have wrote is error proof as of now. We just need the event stream. I used "babeltrace ctf/" command to read the metadata. Here metadata file is residing in ctf/ folder. Thanks -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
>
> This is very good news. Writing the event stream is the easy part. Just
> fwrite() the events in the modified print_item(). Your TSDL in the metadata
> file must describe this event stream.
>
Yes. That's what I am trying today. You suggested that I have to convert
client_item(see below)
typedef struct client_item {
union {
SLIST_ENTRY( client_item ) free_node;
RB_ENTRY( client_item )active_node;
};
uint64_t ns;
uint32_t cpu;
rtems_record_event event;
uint64_t data;
uint64_t counter;
} client_item;
to
typedef struct ctf_event {
uint64_t ns;
uint32_t cpu;
rtems_record_event event;
uint64_t data;
uint64_t counter;
} ctf_event;
I did that but rtems-tools build is failing because I think some part of
the codebase is dependent on
union {
SLIST_ENTRY( client_item ) free_node;
RB_ENTRY( client_item )active_node;
};
How should I deal with it?
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
>
>
> >> This is very good news. Writing the event stream is the easy part. Just
> >> fwrite() the events in the modified print_item(). Your TSDL in the
> metadata
> >> file must describe this event stream.
> >>
> > Yes. That's what I am trying today. You suggested that I have to convert
> > client_item(see below)
> > typedef struct client_item {
> > union {
> >SLIST_ENTRY( client_item ) free_node;
> >RB_ENTRY( client_item )active_node;
> > };
> > uint64_t ns;
> > uint32_t cpu;
> > rtems_record_event event;
> > uint64_t data;
> > uint64_t counter;
> > } client_item;
> >
> > to
> >
> > typedef struct ctf_event {
> > uint64_t ns;
> > uint32_t cpu;
> > rtems_record_event event;
> > uint64_t data;
> > uint64_t counter;
>
> Please remove the counter. It is only used internally in the client.
>
>
> > } ctf_event;
> >
> > I did that but rtems-tools build is failing because I think some part of
> > the codebase is dependent on
> > union {
> >SLIST_ENTRY( client_item ) free_node;
> >RB_ENTRY( client_item )active_node;
> > };
> >
> > How should I deal with it?
>
> Why do you want to change struct client_item? You should create a struct
> ctf_event variable in print_item() on the stack, initialize it with the
> values handed over in the client item and fwrite() it to the event stream.
>
Okay. I have sent the patch. Although it's not working. I tried very much
but it was appending the events.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
*20 June work summary:* Forwarded the response received from babeltrace community. Tried to parse metadata through. It was working fine. Wrote code for storing the event stream in a file and sent the patch for the same. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Write event stream in file
> > seconds = (uint32_t) ( item->ns / 10 );
> > nanoseconds = (uint32_t) ( item->ns % 10 );
> > +ns=nanoseconds;
>
> Why not move the nanoseconds variable into the upper block?
>
Okay
>
> > fprintf( f, "%" PRIu32 ".%09" PRIu32 ":", seconds, nanoseconds );
> > } else {
>
> Which value has "ns" in this path?
>
na does not have a unique value. It is changing eveytime print_item() is
called upon
>
> > fprintf( f, "*:" );
> > @@ -153,6 +164,22 @@ static void print_item( FILE *f, const client_item
> *item )
> > rtems_record_event_text( item->event ),
> > item->data
> > );
> > +
> > + FILE *fptr = fopen("event", "a");
>
> How often gets this file opened and closed? Do you think that opening and
> closing a file is a cheap operation? Could there be a more efficient
> solution?
>
I would like to know your approach. I will implement that only. It's better
to implement your approach instead of mine. It will save some time.
>
> > +
> > + if (fptr == NULL)
> > + {
> > + printf("Could not open file");
> > + return 0;
>
> Can void functions return something?
>
Ooops. I didn't see the void.
>
> > + }
> > +
> > + ctf_item->cpu=item->cpu;
>
> To which object points the the ctf_item pointer here?
>
Are you expecting pointer here?
>
> > + ctf_item->event=item->event;
> > + ctf_item->data=item->data;
> > + ctf_item->ns=ns;
> > +
> > + fprintf(fptr,ctf_item);
> > + fclose(fptr);
> > }
> >
> > static void flush_items( client_context *cctx )
> > --
> > 2.7.4
>
> Did you compile and run the program with this patch?
>
Yes the rtems-tools was building successfully but I was getting nothing in
file.
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Write event stream in file
>
>
> The
>
> static void print_item( FILE *f, const client_item *item )
>
> gets already a file, please use it.
>
> The file is currently stdout. This should be changed to an event stream
> file. Add the file pointer to client_context and open the file in main().
>
> Are you suggesting to change the client_context from
typedef struct client_context {
uint64_t ns_threshold;
uint64_t last_ns;
uint32_t last_cpu;
bool flush;
bool only_one_cpu;
uint64_t counter;
SLIST_HEAD( , client_item )free_items;
RB_HEAD( active, client_item ) active_items;
} client_context;
to
typedef struct client_context {
uint64_t ns_threshold;
uint64_t last_ns;
uint32_t last_cpu;
bool flush;
bool only_one_cpu;
uint64_t counter;
SLIST_HEAD( , client_item )free_items;
RB_HEAD( active, client_item ) active_items;
FILE *fptr;
} client_context;
In this case, I have to create global client_context variable to store the
file pointer in it. Is that good?
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Write event stream in file
Hi, I was able to store the event stream in file. I have sent the patch for the same. It has only one warning that I have to discuss with you. ../misc/record/record-main.c:172:14: warning: ‘ns’ may be used uninitialized in this function [-Wmaybe-uninitialized] ctf_item.ns=ns; ^ ../misc/record/record-main.c:147:12: note: ‘ns’ was declared here uint32_t ns; The ns value is uninitialized because it is not able to receive the value from if block. Should I make uint32_t seconds; uint32_t nanoseconds; above the block? Thanks -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Write event stream in file
Hi, I tried to parse the event stream file and metadata file through babeltrace gives the following error: [error] Invalid magic number 0x30302E30 at packet 0 (file offset 0). [error] Stream index creation error. [error] Open file stream error. [warning] [Context] Cannot open_trace of format ctf at path ctf. [warning] [Context] cannot open trace "ctf" from ctf/ for reading. [error] Cannot open any trace for reading. [error] opening trace "ctf/" for reading. [error] none of the specified trace paths could be opened. I think the metadata file is not compatible with event stream generated. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Write event stream in file
>
> > I was able to store the event stream in file. I have sent the patch for
> > the same. It has only one warning that I have to discuss with you.
> >
> > ../misc/record/record-main.c:172:14: warning: ‘ns’ may be used
> > uninitialized in this function [-Wmaybe-uninitialized]
> > ctf_item.ns=ns;
> >^
> > ../misc/record/record-main.c:147:12: note: ‘ns’ was declared here
> > uint32_t ns;
>
> This is not a warning. It is an error. The ns variable is not set in the
> else path.
>
Should I remove the inner content of if block? Since we are not using
fprintf() anymore.
>
> It should look like this:
>
> static void print_item( FILE *f, const client_item *item )
> {
>ctf_event ctf_item;
>
>ctf_item.ns = item->ns;
>ctf_item.cpu = item->cpu;
>ctf_item.event = item->event;
> ctf_item.data = item->data;
>
>fwrite( &ctf_item, sizeof( ctf_item ), 1, f );
> }
>
Okay
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Write event stream in file
> > > I tried to parse the event stream file and metadata file through > > babeltrace gives the following error: > > > > [error] Invalid magic number 0x30302E30 at packet 0 (file offset 0). > > [error] Stream index creation error. > > [error] Open file stream error. > > [warning] [Context] Cannot open_trace of format ctf at path ctf. > > [warning] [Context] cannot open trace "ctf" from ctf/ for reading. > > [error] Cannot open any trace for reading. > > > > [error] opening trace "ctf/" for reading. > > > > [error] none of the specified trace paths could be opened. > > > > I think the metadata file is not compatible with event stream generated. > > Yes, indeed. I also think that the metadata doesn't describe the event > stream. The metadata should describe the struct ctf_item. > Yes. It needs research. I am not sure how I can make event stream generated compatible with metadata. I have raised a query for the same on lttng. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Write event stream in file
> > >> I tried to parse the event stream file and metadata file through > >> babeltrace gives the following error: > >> > >> [error] Invalid magic number 0x30302E30 at packet 0 (file offset 0). > >> [error] Stream index creation error. > >> [error] Open file stream error. > >> [warning] [Context] Cannot open_trace of format ctf at path ctf. > >> [warning] [Context] cannot open trace "ctf" from ctf/ for reading. > >> [error] Cannot open any trace for reading. > >> > >> [error] opening trace "ctf/" for reading. > >> > >> [error] none of the specified trace paths could be opened. > >> > >> I think the metadata file is not compatible with event stream generated. > > > > Yes, indeed. I also think that the metadata doesn't describe the event > > stream. The metadata should describe the struct ctf_item. > > In your current version you have also calls to fprintf() mixed into the > fwrite() in print_item(). > Should I comment the fprintf() and leave it there or just permanently remove it? -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
*21 June work summary:* I have managed to store event streams in the disk. Tried to parse metadata and event stream file through babeltrace but it showing error as of now because the metadata file is not compatible with it. Raised a query on babletrace list asking about the same. It needs bit of research. > -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: CTF example
Hi,
Thanks for sharing the example.
I managed to store the RTEMs event stream in a file. I have also written
the metada for the same but babeltrace is not able to read CTF because
metadata is not compatible with it.
Do you have any example or approach to make metadata compatible with events?
This is CTF event I am storing in event stream file.
typedef struct ctf_event {
uint64_t ns;
uint32_t cpu;
rtems_record_event event;
uint64_t data;
} ctf_event;
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
GSoC Project | Basic Support for Trace Compass
*Plan of the week:* Last I was able to store the event stream in the disk. Now, I plan to convert the native stream into CTF format. Once the conversion is done then I will make the metadata for the converted CTF format. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
On Mon, Jun 24, 2019 at 12:06 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 24/06/2019 08:24, Ravindra Kumar Meena wrote:
> > *Plan of the week:*
> > Last I was able to store the event stream in the disk. Now, I plan to
> > convert the native stream into CTF format. Once the conversion is done
> > then I will make the metadata for the converted CTF format.
>
> The metadata is an essential part of CTF, so you cannot to this after a
> conversion. The metadata must describe your event stream. Please read
> the CTF specification again:
>
> https://diamon.org/ctf/
>
> All what you need to know about the metadata is described in this
> specification in detail. You should be able to write the metadata for an
> event stream consisting of struct ctf_event items until this Wednesday
> so that babeltrace can read it.
>
Okay. I have figured out something very important.
Babeltrace reads trace files only when the event stream file have ctf magic
number(0xc1fc1fc1) and stream id( ).
The stream data we are generating does not have these. I manually added
these values in the stream file. Babeltrace was reading the trace stream.
This reduced the babeltrace error from
[error] Invalid magic number 0x30302E30 at packet 0 (file offset 0).
[error] Stream index creation error.
[error] Open file stream error.
[warning] [Context] Cannot open_trace of format ctf at path ctf.
[warning] [Context] cannot open trace "ctf" from ctf/ for reading.
[error] Cannot open any trace for reading.
[error] opening trace "ctf/" for reading.
[error] none of the specified trace paths could be opened.
to
[warning] Unknown value 155263 in enum.
0 RTEMS_RECORDING_EVENT: { ns = 0, cpu = 0, events = ( :
container = 155263 ), data = 0 }
[error] Event id 216 is outside range.
[error] Reading event failed.
Error printing trace.
As you can see magic number and many others error are reduced. This proves
that we have to add ctf magic number(0xc1fc1fc1) and stream id(
) in the generated stream file.
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
I am using Ghex software to read and modify the binary file in hexadecimal. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
> > > https://diamon.org/ctf/#spec7 - "Magic number (CTF magic number: > 0xC1FC1FC1) specifies that this is a CTF packet. This magic number is > optional ... Stream ID, used as reference to stream description in > metadata. This field is optional if there is only one stream > description" > > These errors are caused by the metadata mismatch from the stream file, > not by babeltrace. You need to write the metadata to match the trace > data / stream. > The native trace stream in HEX currently looks like this 0400 ed65 7e3d 0d00 010a 6231 5443 5e00 5e00 5e00 0010 0100 0400 61a3 813d 0d00 010a 5e00 5e00 1100 0100 0400 3bb2 843d da0e 0300 0d00 010a Above one is not CTF stream because it does not have CTF magic number So it should look like this in HEX c11f fcc1 0400 ed65 7e3d 0d00 010a 6231 5443 5e00 5e00 5e00 0010 0100 0400 61a3 813d 0d00 010a 5e00 5e00 1100 0100 0400 3bb2 843d da0e 0300 0d00 010a All the example on [1] have this thing in common. I modified the stream file and added magic number(0xc11fcc1) in it. Then, I parsed both stream file and metadata. Babeltrace was able to read the stream file. [1] https://diamon.org/ctf/ -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
*24th June work summary:* Studied the CTF documentation and tried its example. Tried to modify the HEX values of the stream file generated by the QEMU target. Improved the metadata file. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Write event stream in file
> > > Do you get compiler warnings with this version? > No I didn't get any compiler warning or error. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
Hi Sebastian, I have sent the two patches. One is event stream file generation patch and another one is metadata for it. Please apply the patches. Run the following command for like 5 seconds so that it can generate enough event traces. ./build/misc/rtems-record -H 169.254.192.22 -p 1234 | head you will get file named event in folder "rtems-tools". The metadata file is in "misc/ctf/metadata". Please move the event stream file in it. Now, run "babeltrace ctf/" command. Here "ctf" is folder name containing event stream file and metadata. Now you will be able to see that babeltrace is able to read the events. I have cross-checked the the values it is printing. All values(ns,cpu,data) are correct accept the value of events(rtems_record_event). I am currently figuring out why rtems_record_event is giving wrong value. Thanks -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
> > Since the magic number is optional, you should see if you can > construct a simple example metadata and stream file that does not use > the magic number and whether it works with babeltrace or not. > Okay. It worked without magic number. I removed the magic number from both metadata and stream file. The babeltrace was able to read the events. Thanks -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
Hi, First evaluatin of GSoC project has begun. It is from 24th June to 28th June. I would like summarize everything I have done so far. 1. Updated the rtems-docs with the current state of generation of trace record item from the QEMU target. https://github.com/rmeena840/rtems-docs/commit/b8889a84645d2a4bed8f94a5888083d93ff08b20 2. Added event recording trace generation example https://github.com/rmeena840/rtems-docs/commit/68e2239548dac48f533572152a5c8033ff2122b6 3. Successfully stored the trace records items in a stream file. https://github.com/rmeena840/rtems-tools/commit/a213896893d93a25f09f9f00a249fe8e866206c9 4. Wrote metadata for the stream file(In progrss) https://github.com/rmeena840/rtems-tools/commit/490024921ec4c1ba96782aeb86ae1e077e32fb66 These are all major results as of now. I was involved in other activities like communicating with babeltrace community to figure out the solution of a problem and I was also regularly updating my blog [1] as part of my GSoC project. [1] https://rmeena840.github.io/ My Github work place for rtems-tools is [2] and for rtems-docs is [3]. [2] https://github.com/rmeena840/rtems-tools/tree/ravindra-rtems [3] https://github.com/rmeena840/rtems-docs/tree/ravindra-rtems Thanks -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Write event stream in file
> > > Do you get compiler warnings with this version? > > > > > > No I didn't get any compiler warning or error. > > How did you configure the build? Did you somehow disable the warnings? > [242/254] Compiling misc/record/record-main.c > ../misc/record/record-main.c: In function ‘print_item’: > ../misc/record/record-main.c:152:14: warning: variable ‘seconds’ set but > not used [-Wunused-but-set-variable] > uint32_t seconds; >^~~ > ../misc/record/record-main.c: In function ‘handler’: > ../misc/record/record-main.c:161:14: warning: ‘ns’ may be used > uninitialized in this function [-Wmaybe-uninitialized] > ctf_item.ns=ns; > ~~~^~~ > ../misc/record/record-main.c:149:12: note: ‘ns’ was declared here > uint32_t ns; > ^~ > Okay. I also got these warnings after reconfiguring again. This can be resolved if we remove the if block. I think there is no need for it now. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
> > > Hi Sebastian, > > > > I have sent the two patches. One is event stream file generation patch > > and another one is metadata for it. Please apply the patches. > > Could you please check it in your rtems-tools repository. > Yes. I have already updated it. My rtems-tools workplace is https://github.com/rmeena840/rtems-tools/tree/ravindra-rtems > > > > > Run the following command for like 5 seconds so that it can generate > > enough event traces. > > ./build/misc/rtems-record -H 169.254.192.22 -p 1234 | head > > Please change the record client to use a file in the repository. So that > we can test with the same data and without the need to run Qemu. > > > > > you will get file named event in folder "rtems-tools". The metadata file > > is in "misc/ctf/metadata". Please move the event stream file in it. > > > > Now, run "babeltrace ctf/" command. Here "ctf" is folder name containing > > event stream file and metadata. > > > > Now you will be able to see that babeltrace is able to read the events. > > > > I have cross-checked the the values it is printing. All > > values(ns,cpu,data) are correct accept the value of > > events(rtems_record_event). > > > > I am currently figuring out why rtems_record_event is giving wrong value. > > Ok, good. Nice progress. > Thanks :) :) -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Write event stream in file
> > > [242/254] Compiling misc/record/record-main.c > > ../misc/record/record-main.c: In function ‘print_item’: > > ../misc/record/record-main.c:152:14: warning: variable ‘seconds’ set > > but > > not used [-Wunused-but-set-variable] > >uint32_t seconds; > > ^~~ > > ../misc/record/record-main.c: In function ‘handler’: > > ../misc/record/record-main.c:161:14: warning: ‘ns’ may be used > > uninitialized in this function [-Wmaybe-uninitialized] > > ctf_item.ns=ns; > > ~~~^~~ > > ../misc/record/record-main.c:149:12: note: ‘ns’ was declared here > > uint32_t ns; > > ^~ > > > > Okay. I also got these warnings after reconfiguring again. This can be > > resolved if we remove the if block. I think there is no need for it now. > > No, sorry, please fix these warnings immediately. Warnings about > uninitialized variables are very likely a hard error. > Okay. I have resolved the issue. https://github.com/rmeena840/rtems-tools/commit/23aeaa0251e89822ac24108f3d0c34af36b610fb Have a look. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
Hi Sebastian,
Like I said that all values are correct(ns, CPU, data) except
rtems_record_event. This is happening because of byte order issue.
This is the warning output of babeltrace
[warning] Unknown value 927712935936 in enum.
0 RTEMS_RECORDING_EVENT: { ns = 4281426372217274368, cpu = 0, events = (
: container = 927712935936 ), data = 167837702 }
[warning] Unknown value 897648164864 in enum.
0 RTEMS_RECORDING_EVENT: { ns = 4281426372217274368, cpu = 0, events = (
: container = 897648164864 ), data = 32440 }
Whatever value is passed on "ctf_item.data=item->event;" is converted into
big-endian value. That's why it giving huge value e.g 897648164864. See the
above output.
If we change the byte order of 897648164864 then it will be 215 which is in
the range of 0 to 1023. This is what we want.
If we could pass the big-endian value on "ctf_item.data=item->event;" then
it will work fine. I intentionally tried to pass 897648164864 directly to
"ctf_item.data=item->event;" and it was working fine because its byte order
is changed and its new value will be 215.
I tried a few approaches but didn't work for me. Any idea how to deal with
it?
Thanks
>
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Generated event stream metadata file
>
>
> > +/* 1024 events are defined. The events are taking values from 0 to
> 1023. */
> > +typedef enum events_e : uint64_t {
> Does this make the enum forced into a 64-bit integer type?
>
Yes, the rtems_record_event variable is 64 bit.
>
> > +} rtems_record_event;
> > +
> > +trace {
> > +major = 1;
> > +minor = 8;
> > +byte_order = le;
> The byte order may depend on the architecture of the CPU that
> generates the trace, right?
>
Yes. It can depend on architecture as well.
>
> > +};
> > +
> > +stream {
> > +event.header := struct {
> > +uint32_t id;
> > +};
> > +};
> > +
> > +event {
> > +name = "RTEMS_RECORDING_EVENT";
> > +id=0;
> > +fields := struct {
> > + timestamp_t ns;
> > + uint32_t cpu;
> > +rtems_record_event events;
> Is the rtems_record_event in a stream 64-bits?
>
Yes.
I am really stuck here. I am trying every possible way but only one
variable is printing the wrong value in babeltrace.
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
25th June work summary: I sent the two patches today. One is for trace stream file generation and another one is metadata file for the same. Babeltrace is printing only one value wrong rest all values are correct. I think there is byte order issue with it. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
>
> I have only had a look at the specification, but according to
> https://diamon.org/ctf/#spec4.1.3 you can set the global "byte_order" of
> your stream in the trace description of your metadata file and override
> this default behavior for certain types.
> In the metadata file of your repository (
> https://github.com/rmeena840/rtems-tools/blob/ravindra-rtems/misc/ctf/metadata)
> you set trace to:
> trace {
> major = 1;
> minor = 8;
> byte_order = le;
> };
>
Thank you so much, Jan Sommer, for pointing this out.
It worked for me :). I was really struggling with it.
Thanks
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
Hi Sebastian,
I have resolved the issue I was facing with rtems_record_event variable. I
have sent the two patches. One is for stream file generation and another
one is for metadata file for the same. Please apply the patches.
Now, babeltrace is able to read the stream file. I have cross-checked the
value. All are correct.
The output should look like this:
0 RTEMS_RECORDING_EVENT: { ns = 4290192310274097152, cpu = 0, events = (
"RTEMS_RECORD_THREAD_STACK_CURRENT" : container = 209 ), data = 32440 }
0 RTEMS_RECORDING_EVENT: { ns = 4290192310274097152, cpu = 0, events = (
"RTEMS_RECORD_THREAD_SWITCH_IN" : container = 215 ), data = 167837711 }
I am happy to say this completes phase 1 of my GSoC project. :) :)
Thanks
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] Write event stream in file
>
> > + ctf_item.event = __builtin_bswap32( item->event );
>
> Why is there this byte swap?
>
It will set its value in big-endian. Since this value will be passed as
big-endian. I have defined the typealias for the same in the metadata.
typealias integer { size = 64; align = 8; signed = false; byte_order=be; }
:= uint64_t_be;
The trace description in our metadata is
trace {
major = 1;
minor = 8;
byte_order = le;
};
This defines that babeltrace has to read in little-endian byte order.
Hence, giving out correct value.
So basically we are passing big-endian value so that babeltrace can read it
in little-endian.
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
>
>
> I had a look at the metadata file:
>
> typedef enum events_e : uint64_t_be {
>
Because I am passing the item->event value in big-endian byte order. This
will take passed value in big-endian byte order.
Now metadata trace description is in little-endian
trace {
major = 1;
minor = 8;
byte_order = le;
};
It will instruct babeltrace to read the big-endian value in little-endian.
Hence giving us the correct value.
> Why is it like this? Your structure looks like this:
>
> typedef struct ctf_event {
> uint32_t event_id;
> uint64_t ns;
> uint32_t cpu;
> rtems_record_event event;
> uint64_t data;
> } ctf_event;
If you carefully look at the event structure I defined in metadata.
event {
name = "RTEMS_RECORDING_EVENT";
id=0;
fields := struct {
timestamp_t ns;
uint32_t cpu;
rtems_record_event events;
uint64_t data;
};
};
I have defined id=0 here. This instructs babeltrace that new event has
begun and from this point, there will be four values (ns, cpu, events,
data).
Once the babeltrace has read the last value(data). It will again see event
id equal 0 stating that new event has begun and again it will read four
values.
It will become more clear if you see the generated trace in HEX format. I
used Ghex software for the same.
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] Generated event stream metadata file
> > > Is this working right? Please regenerate a single squashed patch. > Check for git errors (no newline at end of file?) > > Just a thought, I'm not sure if it makes sense: Will we eventually > need separate metadata files for each of the 4 kinds of record event > layouts? 32b be, 32b le, 64b be, 64b le? if so, the file name should > probably reflect the options, e.g., metadata-64b-be-record > Sorry, but file name cannot be renamed like this because babeltrace won't be able to read the traces. Babeltrace first looks for a file named metadata and then it looks for the traces matching its description in the same directory. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
Hi I have made some changes. https://github.com/rmeena840/rtems-tools/commit/d487aabaa7606d538b25fd37d07890dfa3a690cf https://github.com/rmeena840/rtems-tools/commit/8149b8846016c0c45fdb7d059f61c1f84a60d190 Babeltrace is printing all values but the end, it prints: [error] Unexpected end of packet. Either the trace data stream is corrupted or metadata description does not match data layout. [error] Reading event failed. Error printing trace. This is happening because the last packet is not fully received as we are running command ./build/misc/rtems-record -H 169.254.159.156 -p 1234 | head for like 5 seconds. Have a look -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
> > To be able to better reproduce issues, could you please: > > 1. record a raw record item stream produced by the Qemu target via the nc > tool in a file (not more than 100KiB) > > 2. add this file to rtems-tools > Okay. Where do I have to add this file? > > 3. modify the record-client program to read from a file if a > --input= command line option is given > Okay. Are you suggesting to add --input= flag to the following command? ./build/misc/rtems-record -H 169.254.159.156 -p 1234 | head -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
26th June Work Summary: Updated the file generation code in rtems-tools with required changes. Improved the metadata for the same. I have squashed the commits. https://github.com/rmeena840/rtems-tools/commit/c0035feab6d99b4aeecdd0d76b049f3e2c7aa9ef https://github.com/rmeena840/rtems-tools/commit/f68b5031f4e6f847239effe677701635316b12fb Attended the weekly meeting on Freenode. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
On Thu, Jun 27, 2019 at 10:53 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 26/06/2019 17:58, Ravindra Kumar Meena wrote: > > 26th June Work Summary: > > > > Updated the file generation code in rtems-tools with required changes. > > Improved the metadata for the same. I have squashed the commits. > > > https://github.com/rmeena840/rtems-tools/commit/c0035feab6d99b4aeecdd0d76b049f3e2c7aa9ef > > > https://github.com/rmeena840/rtems-tools/commit/f68b5031f4e6f847239effe677701635316b12fb > > > > Attended the weekly meeting on Freenode. > > Could you please start a new thread for each daily summary. Please also > don't squash the commits in your development branch. The squashing makes > it difficult to track your work. We can do a big squash before we > integrate the stuff into the upstream rtems-tools. > > How is the progress with this task: > > https://lists.rtems.org/pipermail/devel/2019-June/026306.html > > My time estimate for this is about one day for you. An experienced C > developer can do this in less than 30 minutes. > Is there a way to set the file size for which nc should output? I can get around minimum 500KB of file. I am following this https://linux.die.net/man/1/nc -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
> > > > Is there a way to set the file size for which nc should output? I can > > get around minimum 500KB of file. > > I am following this > > https://linux.die.net/man/1/nc > > You can use dd to reduce the file size, e.g. > > dd if=input-file of=output-file count=131072 > Okay. It worked. I have placed it in mis/record directory. It is a binary file. So I directly made a push to my GitHub rtems-tools repository workplace. https://github.com/rmeena840/rtems-tools/commit/70d527dcf8ae8a5026dd1af79e4d27c5adcbdade Have a look. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
>
> > Okay. It worked. I have placed it in mis/record directory.
> >
> > It is a binary file. So I directly made a push to my GitHub rtems-tools
> > repository workplace.
> >
> https://github.com/rmeena840/rtems-tools/commit/70d527dcf8ae8a5026dd1af79e4d27c5adcbdade
> >
> > Have a look.
>
> For whatever reason this file has only 98304 bytes. The content looks
> all right. So, the next step is to modify the client so that it can read
> from a file instead of the TCP stream.
>
>
I am trying to write code to read from the original raw record item.
Does this follow this structure?
typedef struct client_item {
union {
SLIST_ENTRY( client_item ) free_node;
RB_ENTRY( client_item )active_node;
};
uint64_t ns;
uint32_t cpu;
rtems_record_event event;
uint64_t data;
uint64_t counter;
} client_item;
I am getting wrong value here? I tested with stream data. I am getting the
right values from the binary file.
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
>
> >
> > For whatever reason this file has only 98304 bytes. The content looks
> > all right. So, the next step is to modify the client so that it can
> > read
> > from a file instead of the TCP stream.
> >
> > I am trying to write code to read from the original raw record item.
>
> I am not sure why you want to do this. On which task are you currently
> working?
>
I am working on the 2nd task to modify the record-client program to read
from a file if a --input= command line option is given.
client_item record;
while(fread(&record, sizeof(record), 1, input_file))
printf ("CPU=%d\n",record.cpu);
Here input_file is a file provided through the command.
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
>
> > For whatever reason this file has only 98304 bytes. The
> > content looks
> > > all right. So, the next step is to modify the client so that
> > it can
> > > read
> > > from a file instead of the TCP stream.
> > >
> > > I am trying to write code to read from the original raw record
> item.
> >
> > I am not sure why you want to do this. On which task are you
> currently
> > working?
> >
> > I am working on the 2nd task to modify the record-client program to read
> > from a file if a --input= command line option is given.
>
> Could you please check in the part which adds the new option and the
> code which opens the file.
>
> >
> > client_item record;
> > while(fread(&record, sizeof(record), 1, input_file))
> > printf ("CPU=%d\n",record.cpu);
> >
> > Here input_file is a file provided through the command.
>
> The TCP stream you saved with nc from the target consists of struct
> rtems_record_item_32. In the code above you read struct client_item
> items. This cannot be right. When you don't know which content a file
> has, please ask.
>
typedef struct {
uint32_t event;
uint32_t data;
} rtems_record_item_32;
Okay. Raw file contents have this structure. It means raw file will only
contain event and data in binary format. How should I get it's
corresponding ns and cpu values.
>
> You have to change this code here:
>
>while ( true ) {
> int buf[ 8192 ];
> ssize_t n;
>
> n = recv( fd, buf, sizeof( buf ), 0 );
> if ( n >= 0 ) {
>rtems_record_client_run( &ctx, buf, (size_t) n );
> } else {
>break;
> }
>}
>
> First you should refactor the code and move the TCP relates stuff into
> separate functions.
The command line should like this right?
./build/misc/rtems-record --input= | head
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
> > > Okay. Raw file contents have this structure. It means raw file will only > > contain event and data in binary format. How should I get it's > > corresponding ns and cpu values. > > 1. Instead of the socket() and connect() you open the file descriptor with > open(). > > 2. Instead of using recv() to read from the file descriptor you use > read(). See below. > Wow!!. The file descriptor is a very nice concept. I learned about it during my 3rd year of graduation but I never thought I would ever apply it :) https://www.geeksforgeeks.org/input-output-system-calls-c-create-open-close-read-write/ The 2nd task is complete. Have made a push on my GitHub rtems-tools workplace https://github.com/rmeena840/rtems-tools/commit/362a6fc94886f298d207021ce5f2dad48783c0da Have a look I tried the command on my machine it's working fine with the raw data created today. The babeltrace is able to print all values. I used "./build/misc/rtems-record --input raw_data | head" command generating ctf events from raw data Thanks -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
GSoC Project | Basic support for Trace Compass
27th June Work Summary: Stored compressed version of raw data of size 98 KB generated from QEMU target in misc/record directory. Modified RTEMs client program for --input= flag. It's working fine. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
>
> As I said a couple of time before. Please fix the compiler warnings:
>
> ../misc/record/record-main.c:57:23: warning: character constant too long
> for its type
> { "input", 1, NULL, 'input' },
> ^~~
> ../misc/record/record-main.c: In function ‘main’:
> ../misc/record/record-main.c:308:12: warning: character constant too
> long for its type
> case 'input':
> ^~~
>
> I am a bit surprised that this code compiles at all.
>
> There is a bug (from me) in the while loop.
>
> ssize_t n;
>
> n = ( input_file_flag ) ? read(fd, buf, 10) : recv( fd, buf,
> sizeof( buf ), 0 );
> -if ( n >= 0 ) {
> +if ( n > 0 ) {
> rtems_record_client_run( &ctx, buf, (size_t) n );
> } else {
> break;
>
Okay. Made some changes
https://github.com/rmeena840/rtems-tools/commit/e454fec2ba42cc51bc85a53af2990645be162d77
>
> Could you please give me permission to push to your repository. I would
> like to add a record item stream from a QorIQ T4240.
>
Did you get the invite? My GitHub handle is rmeena840.
>
> lttng seems to create one event stream file per processor. This is your
> next task.
>
> 1. Open a event stream file for each processor.
>
The stream file which has ctf event element?
>
> 2. Write the events of a processor (CPU) to the corresponding file.
>
Sorry, I didn't get this task?
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
GSoC Project | Basic Support for Trace Compass
*Plan of the week:* I will continue to work on the new tasks assigned. https://lists.rtems.org/pipermail/devel/2019-June/026410.html I will update my GSoC blog [1]. [1] https://rmeena840.github.io/ -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
Have made changes for task writing the events of a processor (CPU) to the corresponding file. https://github.com/rmeena840/rtems-tools/commit/111ee2f3f92a0371241d31542d28687431d18097 Have a look -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
*1st July work summary:* Updated the GSoC blog. Worked on the assigned task. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
Have made changes for the task opening an event stream file for each processor. https://github.com/rmeena840/rtems-tools/commit/85029d39eb26bde2e7519d0bd6b2a8f430f13652 Have a look What does binary file you pushed on my workplace has? With the previous file(raw_data), it was generating only one binary file but with the new file(qoriq_e6500_32), it is generating multiple files. > -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
> > Your latest commit has some issues: > > > https://github.com/rmeena840/rtems-tools/commit/85029d39eb26bde2e7519d0bd6b2a8f430f13652 > > You have exactly one input source, this is either a TCP stream or a > input file. > For TCP stream we should have only one file and for the input file, we should have as many files as there stored in variable RTEMS_RECORD_CLIENT_MAXIMUM_CPU_COUNT right? > > For each CPU you have exactly one output file. > > Please don't use sprintf(). Use snprintf() instead. Check the return > value of all functions at least with an assert(). > Okay -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
> > For TCP stream we should have only one file and for the input file, we > > should have as many files as there stored in > > variable RTEMS_RECORD_CLIENT_MAXIMUM_CPU_COUNT right? > > No, you have only one input stream. It doesn't matter if it received via > TCP or read from a file. Why do you think we have many input files? I > really would like to know this. > I mean that for TCP input we should have one output binary file generated and for file input, we should have multiple binary files generated as output. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
> > > I mean that for TCP input we should have one output binary file > > generated and for file input, we should have multiple binary files > > generated as output. > > The input file is just a copy of a stream obtained via TCP. Why should > be the output depend on the medium which delivers your input? > Okay. Have made some changes: https://github.com/rmeena840/rtems-tools/commit/6fb677ce9da9055c904cb89b5b3612557ed995fd Have a look. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
>
> >
> > Okay. Have made some changes:
> >
> https://github.com/rmeena840/rtems-tools/commit/6fb677ce9da9055c904cb89b5b3612557ed995fd
>
> How many input file descriptors should this program use?
I think it has to be equal to the value in defined
variable RTEMS_RECORD_CLIENT_MAXIMUM_CPU_COUNT.
for( i = 0; i < RTEMS_RECORD_CLIENT_MAXIMUM_CPU_COUNT ; i++ ){
fd[ i ] = ( input_file_flag ) ? open( input_file, O_RDONLY ) :
socket( PF_INET, SOCK_STREAM, 0 );
assert( fd[i] >= 0 );
}
--
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
<https://www.iitism.ac.in/>, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
> > > How many input file descriptors should this program use? > > > > I think it has to be equal to the value in defined > > variable RTEMS_RECORD_CLIENT_MAXIMUM_CPU_COUNT. > > No, as I said before. You need exactly one input file. It is an absolute > miracle to me, why you try to use multiple input files. It makes not > sense at all from my point of view. > Okay. I have used only one file descriptor. https://github.com/rmeena840/rtems-tools/commit/a67decf3882db81970d88d3507763bf12627cbb6 Have a look. -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Project | Basic Support for Trace Compass
2nd July work summary: Completed assigned task to open an event stream file for each processor. Tried to modify metadata for the new event stream file(not complete). -- *Ravindra Kumar Meena*, B. Tech. Computer Science and Engineering, Indian Institute of Technology (Indian School of Mines) <https://www.iitism.ac.in/>, Dhanbad ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
