GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> >     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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190618/b5fb7f3c/attachment-0002.html>