shell output
Mathew Benson
mbenson at windhoverlabs.com
Fri Nov 1 16:18:28 UTC 2019
"SHED" = scheduler_name, but that traces back to:
name.name_u32 = _Thread_Scheduler_get_home( rtems_thread )->name;
_Objects_Name_to_string(
name,
false,
canonical_task->scheduler_name,
sizeof( canonical_task->scheduler_name )
);
Shelve that one until later...
"STATE" = state. That traces back to rtems_monitor_dump_state()... which
eventually traces back to:
static const rtems_assoc_32_pair state_pairs[] = {
{ STATES_WAITING_FOR_MUTEX, "MTX" },
{ STATES_WAITING_FOR_SEMAPHORE, "SEM" },
{ STATES_WAITING_FOR_EVENT, "EV" },
{ STATES_WAITING_FOR_SYSTEM_EVENT, "SYSEV" },
{ STATES_WAITING_FOR_MESSAGE, "MSG" },
{ STATES_WAITING_FOR_CONDITION_VARIABLE, "CV" },
{ STATES_WAITING_FOR_FUTEX, "FTX" },
{ STATES_WAITING_FOR_BSD_WAKEUP, "WK" },
{ STATES_WAITING_FOR_TIME, "TIME" },
{ STATES_WAITING_FOR_PERIOD, "PER" },
{ STATES_WAITING_FOR_SIGNAL, "SIG" },
{ STATES_WAITING_FOR_BARRIER, "BAR" },
{ STATES_WAITING_FOR_RWLOCK, "RW" },
{ STATES_WAITING_FOR_JOIN_AT_EXIT, "JATX" },
{ STATES_WAITING_FOR_JOIN, "JOIN" },
{ STATES_SUSPENDED, "SUSP" },
{ STATES_WAITING_FOR_SEGMENT, "SEG" },
{ STATES_LIFE_IS_CHANGING, "LIFE" },
{ STATES_DEBUGGER, "DBG" },
{ STATES_INTERRUPTIBLE_BY_SIGNAL, "IS" },
{ STATES_WAITING_FOR_RPC_REPLY, "RPC" },
{ STATES_ZOMBIE, "ZOMBI" },
{ STATES_DORMANT, "DORM" }
modes traces t o rtems_monitor_dump_modes(), which eventually traces to:
static const rtems_assoc_t rtems_monitor_modes_assoc[] = {
{ "nP", RTEMS_NO_PREEMPT, 0 },
{ "T", RTEMS_TIMESLICE, 0 },
{ "nA", RTEMS_NO_ASR, 0 },
{ 0, 0, 0 },
};
On Fri, Nov 1, 2019 at 11:07 AM Mathew Benson <mbenson at windhoverlabs.com>
wrote:
> The task command doesn't appear to be defined there. I found the header
> in libmisc/monitor/mon-task.c:rtems_monitor_task_dump_header(). It gets a
> little buried in function callbacks from there. I'm trying to trace it
> back now, but I recommend the documentation be improved to include what the
> output actually means.
>
> On Fri, Nov 1, 2019 at 9:50 AM Jonathan Brandmeyer <
> jbrandmeyer at planetiq.com> wrote:
>
>> cpukit/libmisc/shell/ has many of the entry points for the shell
>> functions.
>>
>> On Fri, Nov 1, 2019 at 6:39 AM <mbenson at windhoverlabs.com> wrote:
>>
>>> I take it that’s a no on the documentation. Can somebody just tell me
>>> what these mean or point me where in the code it is? It’s not an easy
>>> follow.
>>>
>>> Sent from my iPhone
>>>
>>> On Oct 31, 2019, at 13:43, Mathew Benson <mbenson at windhoverlabs.com>
>>> wrote:
>>>
>>> is there any documentation that explains the actual output of the shell
>>> commands? For example, the documentation for the task command says how to
>>> run it, and gives the following sample output:
>>>
>>> SHLL [/] # task
>>> ID NAME SHED PRI STATE MODES EVENTS WAITINFO
>>> ------------------------------------------------------------------------------
>>> 0a010001 UI1 UPD 254 EV P:T:nA NONE
>>> 0a010002 SHLL UPD 100 READY P:T:nA NONE
>>>
>>>
>>> But doesn't actually explain what the data in the columns mean. What do
>>> the following "STATE" values mean: EV, SIG:IS, READY, MSG, SEM, and TIME?
>>> What do the MODES mean? Same question for the "sema" command output.
>>>
>>> --
>>> *Mathew Benson*
>>> CEO | Chief Engineer
>>> Windhover Labs, LLC
>>> 832-640-4018
>>>
>>>
>>> www.windhoverlabs.com
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>>
>>
>>
>> --
>> Jonathan Brandmeyer
>> Vice President of Software Engineering
>> PlanetiQ
>>
>
>
> --
> *Mathew Benson*
> CEO | Chief Engineer
> Windhover Labs, LLC
> 832-640-4018
>
>
> www.windhoverlabs.com
>
>
--
*Mathew Benson*
CEO | Chief Engineer
Windhover Labs, LLC
832-640-4018
www.windhoverlabs.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20191101/57c80d5c/attachment-0001.html>
More information about the users
mailing list