[PATCH] Add configuration option for single processor applications

[Richi Dubey]

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?

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


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210322/fd3e5e83/attachment-0001.html>