[GSOC - Tracing] Status Update

[Gedare Bloom]

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.
>