GSoC Project | Basic Support for Trace Compass

[Ravindra Kumar Meena]

>
> > What I understand from here is that _prev_state is the previous state of
> > the thread(TID)).
>
> Yes, but what is the meaning of these state values? We have to figure this
> out since we need a mapping from RTEMS thread states to these Linux thread
> states. Could you use an example trace from Linux to check if the
> information referenced in this email answer makes sense?
>

$ grep "#define TASK_" include/linux/sched.h
#define TASK_RUNNING                    0x0000
#define TASK_INTERRUPTIBLE              0x0001
#define TASK_UNINTERRUPTIBLE            0x0002
#define TASK_PARKED                     0x0040
#define TASK_DEAD                       0x0080
#define TASK_WAKEKILL                   0x0100
#define TASK_WAKING                     0x0200
#define TASK_NOLOAD                     0x0400
#define TASK_NEW                        0x0800
#define TASK_STATE_MAX                  0x1000
#define TASK_KILLABLE                   (TASK_WAKEKILL |
TASK_UNINTERRUPTIBLE)
#define TASK_STOPPED                    (TASK_WAKEKILL | __TASK_STOPPED)
#define TASK_TRACED                     (TASK_WAKEKILL | __TASK_TRACED)
#define TASK_IDLE                       (TASK_UNINTERRUPTIBLE | TASK_NOLOAD)
#define TASK_NORMAL                     (TASK_INTERRUPTIBLE |
TASK_UNINTERRUPTIBLE)
#define TASK_REPORT                     (TASK_RUNNING | TASK_INTERRUPTIBLE
| \

In babeltrace output _prev_state have { 0, 1, 1026, 4096 } values.
If you have look at above #define <TASK_*>. They have been defined in hex
format.
eg.
0 is 0x0000 which means TASK_RUNNING
1 is 0x0001 which means TASK_INTERRUPTIBLE
1026 in decimal is 0x402 which is 0x400 | 0x002. That is TASK_NOLOAD |
TASK_UNINTERRUPTIBLE, or, as defined above, it's simply TASK_IDLE.

So in this way, all the prev_state are defined.

>
> >
> >
> >> It would be good to get task names for the IDs. Do you have an idea how
> >> we can do this?
> >>
> > With task name do you mean RTEMS_RECORD_THREAD_SWITCH_IN
> > and RTEMS_RECORD_THREAD_SWITCH_OUT?
> >
> > if so this can be done by calling:
> > rtems_record_event_text( item->event )
>
> Attached is a patch for RTEMS. The record server sends all thread names to
> the client after the header.
>
> For thread name changes and new threads we have to think about.
>
I applied the patch. The bootstrap worked successfully. I am not sure what
I have to do with this.


-- 
*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/20190729/c4506708/attachment-0002.html>