<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">That depends. I don't think the CPP will handle string concatenation<br>so well, so a long string like that can cause an exception to the<br>rule. Otherwise you would end up with something like<br>  #ifndef CONFIGURE_MAXIMUM_PROCESSORS<br>    #error "CONFIGURE_MAXIMUM_PROCESSORS must be defined to \<br>configure the EDF SMP scheduler"<br>  #endif<br>which is worse. It might be possible through some other means though, like<br>#ifndef CONFIGURE_MAXIMUM_PROCESSORS<br>#error "CONFIGURE_MAXIMUM_PROCESSORS must be defined" ## \<br>            "to configure the EDF SMP scheduler"<br>#endif<br>But again, it is probably better just to let it spill over length than<br>to make it more complex by this manner.</blockquote><div>I understand, Thanks for the clarification.</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think I wrote the first version of this :)<br><a href="https://gedare.github.io/pdf/bloom_scheduling_2014.pdf" rel="noreferrer" target="_blank">https://gedare.github.io/pdf/bloom_scheduling_2014.pdf<br></a>Now things are a little bit more complicated by SMP. Capturing this<br>knowledge is important.</blockquote><div>Got it. Thanks! </div><div class="gmail-yj6qo gmail-ajU" style="outline:none;padding:10px 0px;width:22px;margin:2px 0px 0px"><br class="gmail-Apple-interchange-newline"></div></div><div> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 22, 2021 at 11:08 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 Sun, Mar 21, 2021 at 11:48 PM Richi Dubey <<a href="mailto:richidubey@gmail.com" target="_blank">richidubey@gmail.com</a>> wrote:<br>
><br>
> Hi!<br>
><br>
> Thanks for your review.<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>
>> I guess that is the "right way" to put the onus on the application to<br>
>> specify their configuration properly.<br>
><br>
> 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?<br>
><br>
<br>
That depends. I don't think the CPP will handle string concatenation<br>
so well, so a long string like that can cause an exception to the<br>
rule. Otherwise you would end up with something like<br>
  #ifndef CONFIGURE_MAXIMUM_PROCESSORS<br>
    #error "CONFIGURE_MAXIMUM_PROCESSORS must be defined to \<br>
configure the EDF SMP scheduler"<br>
  #endif<br>
which is worse. It might be possible through some other means though, like<br>
#ifndef CONFIGURE_MAXIMUM_PROCESSORS<br>
#error "CONFIGURE_MAXIMUM_PROCESSORS must be defined" ## \<br>
            "to configure the EDF SMP scheduler"<br>
#endif<br>
<br>
But again, it is probably better just to let it spill over length than<br>
to make it more complex by this manner.<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.<br>
><br>
> Yes, some of the errors in our Strong APA scheduler (code or logic) was discovered by failing non scheduler tests.<br>
>><br>
>> 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>
> Okay, I am on it. How to write a scheduler: RTEMS edition coming soon on <a href="https://rtemswithrichi.wordpress.com/" rel="noreferrer" target="_blank">https://rtemswithrichi.wordpress.com/</a> :p<br>
<br>
I think I wrote the first version of this :)<br>
<a href="https://gedare.github.io/pdf/bloom_scheduling_2014.pdf" rel="noreferrer" target="_blank">https://gedare.github.io/pdf/bloom_scheduling_2014.pdf</a><br>
Now things are a little bit more complicated by SMP. Capturing this<br>
knowledge is important.<br>
<br>
><br>
><br>
> 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>
>><br>
>> 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>