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