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