>
> Where did you find what?
>
In babeltrace output the value of _prev_state is always 0, 1, 1026 but
mostly it is 0 or 1. There is no fixed pattern in the value of _prev_state
in babeltrace output.
_prev_state is a member of event.field.
>
> I found:
>
> event {
> name = "sched_switch";
> id = 22;
> stream_id = 0;
> fields := struct {
> integer { size = 8; align = 8; signed = 0; encoding =
> UTF8; base = 10;
> } _prev_comm[16];
> integer { size = 32; align = 8; signed = 1; encoding =
> none; base =
> 10; } _prev_tid;
> integer { size = 32; align = 8; signed = 1; encoding =
> none; base =
> 10; } _prev_prio;
> integer { size = 64; align = 8; signed = 1; encoding =
> none; base =
> 10; } _prev_state;
> integer { size = 8; align = 8; signed = 0; encoding =
> UTF8; base = 10;
> } _next_comm[16];
> integer { size = 32; align = 8; signed = 1; encoding =
> none; base =
> 10; } _next_tid;
> integer { size = 32; align = 8; signed = 1; encoding =
> none; base =
> 10; } _next_prio;
> };
> };
>
> I think the analysis tools learns the id from the event name, see
> "lttng-track-process" in lttng-analyses.
>
> Can you please align all the metadata exactly with the way things are
> defined in LTTNG.
>
Okay. Sure
>
> >
> > There is one problem here we need the next_comm and next_tid value
> > before actually next record item is generated in client-side.
>
> You need one sched_switch event per processor. The order of record
> events is fixed. You update the sched_switch event in two steps and
> write it to the stream after the second step.
>
Okay. Thanks
--
*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
