"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 <mben...@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 < > jbrandme...@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 <mben...@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 <mben...@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@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
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users