>
> This approach makes no sense to me.
>
> Per CPU you receive three record events in succession:
>
> [19:32:26.679099590] (+0.000046608) Record_Item RTEMS_RECORDING_EVENT: {
> cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_SWITCH_OUT" : container =
> 216 ), data = 167837707 }
> [19:32:26.679099590] (+0.000000000) Record_Item RTEMS_RECORDING_EVENT: {
> cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_STACK_CURRENT" :
> container = 209 ), data = 32320 }
> [19:32:26.679099590] (+0.000000000) Record_Item RTEMS_RECORDING_EVENT: {
> cpu_id = 5 }, { event = ( "RTEMS_RECORD_THREAD_SWITCH_IN" : container =
> 215 ), data = 151060501 }
>
> They have all the same timestamp.
>
> When you receive an RTEMS_RECORD_THREAD_SWITCH_OUT event, you store the
> timestamp (per CPU) and the data (per-CPU, this is the thread ID).
>
> When you receive an RTEMS_RECORD_THREAD_SWITCH_IN event and the
> timestamp matches, you use the values of the current event and the
> values stored before to output an LTTNG sched_switch event.
>I am trying this approach but I think there is one problem with it. When RTEMS_RECORD_THREAD_SWITCH_IN event is received then there is no way to receive it's next_* values. e.g. ab //RTEMS_RECORD_THREAD_SWITCH_OUT bc //RTEMS_RECORD_THREAD_STACK_CURRENT cd //RTEMS_RECORD_THREAD_SWITCH_IN Think this example as output in babeltrace where first character is of prev_comm value and second character is of next_comm value. Since we will be writing just after receiving c(third row) we can't get d values. For this, we should have d value so that we can write it in RTEMS_RECORD_THREAD_SWITCH_IN event with next_comm value. -- *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
