[PATCH] Add configuration option for single processor applications

[Gedare Bloom]

On Sun, Mar 21, 2021 at 11:48 PM Richi Dubey <richidubey at gmail.com> wrote:
>
> Hi!
>
> Thanks for your review.
>
>> Why not just copy how SMP EDF deals with this problem?
>> https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L124
>> I guess that is the "right way" to put the onus on the application to
>> specify their configuration properly.
>
> 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?
>

That depends. I don't think the CPP will handle string concatenation
so well, so a long string like that can cause an exception to the
rule. Otherwise you would end up with something like
  #ifndef CONFIGURE_MAXIMUM_PROCESSORS
    #error "CONFIGURE_MAXIMUM_PROCESSORS must be defined to \
configure the EDF SMP scheduler"
  #endif
which is worse. It might be possible through some other means though, like
#ifndef CONFIGURE_MAXIMUM_PROCESSORS
#error "CONFIGURE_MAXIMUM_PROCESSORS must be defined" ## \
            "to configure the EDF SMP scheduler"
#endif

But again, it is probably better just to let it spill over length than
to make it more complex by this manner.

>> I never thought too much about this. I guess, it means we expect the
>> scheduler-specific tests do a sufficient job to exercise the scheduler
>> implementations that we can rely on the default scheduler to "just
>> work" in the other tests. Which makes sense although you have stumbled
>> over some scheduler-specific bugs that are uncovered by these
>> non-scheduler tests.
>
> Yes, some of the errors in our Strong APA scheduler (code or logic) was discovered by failing non scheduler tests.
>>
>> Documenting your approach to developing and
>> debugging a scheduler may help the next person who tries. :) We don't
>> have a great place for that kind of guidance, so I guess clear blog
>> posts are helpful for now.
>
> Okay, I am on it. How to write a scheduler: RTEMS edition coming soon on https://rtemswithrichi.wordpress.com/ :p

I think I wrote the first version of this :)
https://gedare.github.io/pdf/bloom_scheduling_2014.pdf
Now things are a little bit more complicated by SMP. Capturing this
knowledge is important.

>
>
> On Thu, Mar 18, 2021 at 2:15 AM Gedare Bloom <gedare at rtems.org> wrote:
>>
>> Hi Richi,
>>
>> On Wed, Mar 17, 2021 at 1:06 PM Sebastian Huber
>> <sebastian.huber at embedded-brains.de> wrote:
>> >
>> > On 17/03/2021 19:00, Richi Dubey wrote:
>> >
>> > > Thanks for your quick review.
>> > >
>> > >     I think this patch is superfluous. In which scenario do you think
>> > >     it is
>> > >     necessary?
>> > >
>> > > It is from this mail conversation:
>> > > https://lists.rtems.org/pipermail/devel/2020-September/061845.html
>> > > <https://lists.rtems.org/pipermail/devel/2020-September/061845.html>
>> > > followed by
>> > > https://lists.rtems.org/pipermail/devel/2020-September/061846.html
>> > > <https://lists.rtems.org/pipermail/devel/2020-September/061846.html>.
>> > For the tests you just need a temporary hack.
>> > >
>> > > Strong APA uses the value of CONFIGURE_MAXIMUM_PROCESSORS in its
>> > > declaration
>> > > <https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L260>
>> > > at cpukit/include/rtems/scheduler.h. This addition would be necessary
>> > > to support future SMP schedulers that need to know the number of CPUs
>> > > in the system at the time of configuration.
>>
>> Can you use _CONFIGURE_MAXIMUM_PROCESSORS there?
>>
>> Why not just copy how SMP EDF deals with this problem?
>> https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L124
>>
>> I guess that is the "right way" to put the onus on the application to
>> specify their configuration properly.
>>
>> > In general, it makes no sense to use an SMP scheduler on a system with
>> > just one processor. If you really want to do this, then you have to
>> > explicitly define CONFIGURE_MAXIMUM_PROCESSORS to 1 in your application
>> > configuration.
>> >
>>
>> I never thought too much about this. I guess, it means we expect the
>> scheduler-specific tests do a sufficient job to exercise the scheduler
>> implementations that we can rely on the default scheduler to "just
>> work" in the other tests. Which makes sense although you have stumbled
>> over some scheduler-specific bugs that are uncovered by these
>> non-scheduler tests. Documenting your approach to developing and
>> debugging a scheduler may help the next person who tries. :) We don't
>> have a great place for that kind of guidance, so I guess clear blog
>> posts are helpful for now.
>>
>> -Gedare
>> >
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel