On Fri, Jul 31, 2020 at 5:48 AM Richi Dubey <richidu...@gmail.com> wrote: > > Thank you for your answer. I learned ack today and it is coming pretty handy > along with cscope. > Note that 'grep' is more reliable, but takes a bit more time to run. 'ack' filters the files that it checks, so it can miss things sometimes.
> On Thu, Jul 30, 2020 at 9:32 PM Gedare Bloom <ged...@rtems.org> wrote: >> >> On Thu, Jul 30, 2020 at 7:30 AM Richi Dubey <richidu...@gmail.com> wrote: >> > >> > I request someone to help me with my earlier question: >> > https://lists.rtems.org/pipermail/devel/2020-July/060615.html since I may >> > reuse this logic of variable-sized arrays. >> > >> >> I guess I'll answer here.. >> >> rtems$ ack Scheduler_EDF_SMP_Context >> cpukit/score/src/scheduleredfsmp.c >> 24:static inline Scheduler_EDF_SMP_Context * >> 27: return (Scheduler_EDF_SMP_Context *) _Scheduler_Get_context( scheduler >> ); >> 30:static inline Scheduler_EDF_SMP_Context * >> 33: return (Scheduler_EDF_SMP_Context *) context; >> 63: Scheduler_EDF_SMP_Context *self = >> 100: Scheduler_EDF_SMP_Context *self = _Scheduler_EDF_SMP_Get_self( context >> ); >> 121: Scheduler_EDF_SMP_Context *self, >> 143: Scheduler_EDF_SMP_Context *self; >> 192: Scheduler_EDF_SMP_Context *self, >> 201: const Scheduler_EDF_SMP_Context *self, >> 220: Scheduler_EDF_SMP_Context *self; >> 241: Scheduler_EDF_SMP_Context *self; >> 284: Scheduler_EDF_SMP_Context *self; >> 307: Scheduler_EDF_SMP_Context *self; >> 370: Scheduler_EDF_SMP_Context *self; >> 586: Scheduler_EDF_SMP_Context *self; >> >> cpukit/include/rtems/score/scheduleredfsmp.h >> 106:} Scheduler_EDF_SMP_Context; >> >> cpukit/include/rtems/scheduler.h >> 133: Scheduler_EDF_SMP_Context Base; \ >> >> That last one is part of an allocation. >> >> > Thank you. >> > >> > On Sat, Jul 18, 2020 at 6:29 PM Richi Dubey <richidu...@gmail.com> wrote: >> >> >> >> This information helps. Thank you. >> >> >> >> On Fri, Jul 17, 2020 at 6:31 PM Sebastian Huber >> >> <sebastian.hu...@embedded-brains.de> wrote: >> >> > >> >> > On 17/07/2020 14:22, Richi Dubey wrote: >> >> > >> >> > > I found the line in the documentation: "Since the processor assignment >> >> > > is independent of the thread priority the processor indices may move >> >> > > from one state to the other." >> >> > > >> >> > > This is true because the processor assignment is done by the scheduler >> >> > > and it gets to choose whether to allocate the highest priority thread >> >> > > or not. Right? So if it wants to allocate processor to the lowest >> >> > > priority (max. priority number) thread, it can do so? >> >> > Yes, the scheduler can use whatever criteria it wants to allocate a >> >> > processor to the threads is manages. >> >> > > >> >> > > How is the priority of a node different from the priority of its >> >> > > thread? How do these two priorities relate to each other? >> >> > A thread has not only one priority. It has at least one priority per >> >> > scheduler instance. With the locking protocols it may also inherit >> >> > priorities of other threads. A thread has a list of trees of trees of >> >> > priorities. >> > >> > _______________________________________________ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
