[GSOC - Tracing] Status Update

Tue Jul 3 02:20:14 UTC 2018

> 3. Clearly document your modifications in separate commit messages.

> 4. Add a Makefile to build it automatically.

I will push commits to a fork of the rtems. Have given a link to the
repository in the readme.md of the Tracing repo. Will that be okay?

> 6. Document the steps involved in the tracing, e.g. trace data generation
on the RTEMS target, transfer of the data to the development host,
conversion of trace data in format X to Y using tool Z, etc. Document the
interfaces between the different steps and what runs on the RTEMS target
and what runs on the development host.

Done

> To get the trace data from the simulator to the development host, you can
just dump the data via printf() and parse it on the host. This is slow, but
enough for a test scenario.

I have tested the babeltrace conversion by saving the console output to a
text file on host manually (https://vidushivashishth.github.io/eighthpost/).
Can I use sockets to transport the traces from target to host instead? Will
that be feasible? I have already created a client and server side program
and tested a text file transfer. This is working.

> Either we should use barectf to generate CTF traces in RTEMS, we
> should implement our own CTF generator in RTEMS, or we should provide
> a converter for running babeltrace on a host (Linux/MacOS/etc) to
> convert from RTEMS trace linker format to CTF.

I am implementing the last option.

On Tue, Jul 3, 2018 at 1:37 AM, Gedare Bloom <gedare at rtems.org> wrote:

> On Mon, Jul 2, 2018 at 1:27 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
> > Hello Vidushi,
> >
> > On 29/06/18 09:44, Vidushi Vashishth wrote:
> >>
> >>
> >>         >Could you please create a self-contained repository which
> >> contains
> >>
> >>         >* a README
> >>
> >>         >* a simple RTEMS application which runs on a simulator BSP
> >>
> >>         >* the stuff that makes it possible to view the trace output
> >>         (it is not a problem if it doesn't work, but all pieces should
> >>         be included)
> >>
> >>         >The repository should not be a clone of some larger project.
> >>         It may contain external references as submodules.
> >>
> >>         Okay. Got it. I will update you when its done.
> >>
> >>
> >>     Ok, do you have a time estimate for this? Which parts are missing?
> >>
> >>
> >> Viewing the trace output is buggy right now. I will have to combine the
> >> rest. I will push the required things in the repository by end of today
> and
> >> notify you.
> >>
> >
> > the stuff you published here
> >
> > https://github.com/VidushiVashishth/Tracing
> >
> > yesterday (this is not "by end of today") is not much considering this
> the
> > 8th week of the GSoC project.
> >
> > You seem to have imported cpukit/libmisc/shell/main_rtrace.c and
> modified
> > it. The modifications are not visible in the repository history. Why did
> yo
> > copy this file out of the RTEMS sources at all?
> >
> > There is no Makefile (or similar). You have to read the documentation to
> > build it. You cannot copy and past the instructions to build it since it
> > contains your local paths.
> >
> > The test data is generated with user input.
> >
> > How can I transfer the test data generated on the simulator to my host
> > development system?
> >
> > I asked for a self-contained repository, with"the stuff that makes it
> > possible to view the trace output". This is missing.
> >
> > Could you please:
> >
> > 1. Not copy sources out of the RTEMS repository. Before you do this, ask
> on
> > the mailing list and explain why have have to do it.
> >
> > 2. If you import things, then import the original files and state the
> > origin.
> >
> > 3. Clearly document your modifications in separate commit messages.
> >
> > 4. Add a Makefile to build it automatically.
> >
> > 5. Add the missing stuff that makes it possible to view the trace
> output. If
> > something is not available yet, then no problem. Just document the
> > interfaces and what it is supposed to do.
> >
> > 6. Document the steps involved in the tracing, e.g. trace data
> generation on
> > the RTEMS target, transfer of the data to the development host,
> conversion
> > of trace data in format X to Y using tool Z, etc. Document the interfaces
> > between the different steps and what runs on the RTEMS target and what
> runs
> > on the development host.
> >
> > To get the trace data from the simulator to the development host, you can
> > just dump the data via printf() and parse it on the host. This is slow,
> but
> > enough for a test scenario.
> >
> > You should be able to do this in a couple of hours.
> >
>
> I'm trying to catch up. I generally agree with all this. Also, I do
> not see any reason ever to try to run babeltrace from RTEMS. I don't
> know if that is being attempted, but it is not a worthwhile effort.
> Either we should use barectf to generate CTF traces in RTEMS, we
> should implement our own CTF generator in RTEMS, or we should provide
> a converter for running babeltrace on a host (Linux/MacOS/etc) to
> convert from RTEMS trace linker format to CTF.
>
> Gedare
>
> >
> > --
> > Sebastian Huber, embedded brains GmbH
> >
> > Address : Dornierstr. 4, D-82178 Puchheim, Germany
> > Phone   : +49 89 189 47 41-16
> > Fax     : +49 89 189 47 41-09
> > E-Mail  : sebastian.huber at embedded-brains.de
> > PGP     : Public key available on request.
> >
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180703/fac36376/attachment.html>