GSoC Project | Basic Support for Trace Compass

[Sebastian Huber]

On 18/06/2019 13:44, Ravindra Kumar Meena wrote:
>      >     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.

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

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.

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

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

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