Thread 2: Need help in understanding exisiting RTEMS code

[Richi Dubey]

Thank you for your answer. I learned ack today and it is coming pretty
handy along with cscope.

On Thu, Jul 30, 2020 at 9:32 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Thu, Jul 30, 2020 at 7:30 AM Richi Dubey <richidubey at 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 <richidubey at gmail.com>
> wrote:
> >>
> >> This information helps. Thank you.
> >>
> >> On Fri, Jul 17, 2020 at 6:31 PM Sebastian Huber
> >> <sebastian.huber at 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 at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200731/73b2dab1/attachment.html>