<div dir="ltr">Hi!<br><div><br></div><div>Thanks for your review.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Why not just copy how SMP EDF deals with this problem?<br><a href="https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L124" rel="noreferrer" target="_blank">https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L124</a><br>I guess that is the "right way" to put the onus on the application to<br>specify their configuration properly.</blockquote><div>This seems like the right way and I completely understand. I am going to use a similar strategy. btw line 125 exceeds the 80 char limit, is that okay for header files?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I never thought too much about this. I guess, it means we expect the<br>scheduler-specific tests do a sufficient job to exercise the scheduler<br>implementations that we can rely on the default scheduler to "just<br>work" in the other tests. Which makes sense although you have stumbled<br>over some scheduler-specific bugs that are uncovered by these<br>non-scheduler tests. </blockquote><div>Yes, some of the errors in our Strong APA scheduler (code or logic) was discovered by failing non scheduler tests. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Documenting your approach to developing and<br>debugging a scheduler may help the next person who tries. :) We don't<br>have a great place for that kind of guidance, so I guess clear blog<br>posts are helpful for now.</blockquote><div>Okay, I am on it. <i>How to write a scheduler: RTEMS edition</i> coming soon on <a href="https://rtemswithrichi.wordpress.com/" target="_blank">https://rtemswithrichi.wordpress.com/</a> :p </div><div> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 18, 2021 at 2:15 AM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">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">Hi Richi,<br>
<br>
On Wed, Mar 17, 2021 at 1:06 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/03/2021 19:00, Richi Dubey wrote:<br>
><br>
> > Thanks for your quick review.<br>
> ><br>
> >     I think this patch is superfluous. In which scenario do you think<br>
> >     it is<br>
> >     necessary?<br>
> ><br>
> > It is from this mail conversation:<br>
> > <a href="https://lists.rtems.org/pipermail/devel/2020-September/061845.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-September/061845.html</a><br>
> > <<a href="https://lists.rtems.org/pipermail/devel/2020-September/061845.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-September/061845.html</a>><br>
> > followed by<br>
> > <a href="https://lists.rtems.org/pipermail/devel/2020-September/061846.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-September/061846.html</a><br>
> > <<a href="https://lists.rtems.org/pipermail/devel/2020-September/061846.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-September/061846.html</a>>.<br>
> For the tests you just need a temporary hack.<br>
> ><br>
> > Strong APA uses the value of CONFIGURE_MAXIMUM_PROCESSORS in its<br>
> > declaration<br>
> > <<a href="https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L260" rel="noreferrer" target="_blank">https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L260</a>><br>
> > at cpukit/include/rtems/scheduler.h. This addition would be necessary<br>
> > to support future SMP schedulers that need to know the number of CPUs<br>
> > in the system at the time of configuration.<br>
<br>
Can you use _CONFIGURE_MAXIMUM_PROCESSORS there?<br>
<br>
Why not just copy how SMP EDF deals with this problem?<br>
<a href="https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L124" rel="noreferrer" target="_blank">https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L124</a><br>
<br>
I guess that is the "right way" to put the onus on the application to<br>
specify their configuration properly.<br>
<br>
> In general, it makes no sense to use an SMP scheduler on a system with<br>
> just one processor. If you really want to do this, then you have to<br>
> explicitly define CONFIGURE_MAXIMUM_PROCESSORS to 1 in your application<br>
> configuration.<br>
><br>
<br>
I never thought too much about this. I guess, it means we expect the<br>
scheduler-specific tests do a sufficient job to exercise the scheduler<br>
implementations that we can rely on the default scheduler to "just<br>
work" in the other tests. Which makes sense although you have stumbled<br>
over some scheduler-specific bugs that are uncovered by these<br>
non-scheduler tests. Documenting your approach to developing and<br>
debugging a scheduler may help the next person who tries. :) We don't<br>
have a great place for that kind of guidance, so I guess clear blog<br>
posts are helpful for now.<br>
<br>
-Gedare<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>