[PATCH] Add configuration option for single processor applications
gedare at rtems.org
Wed Mar 17 20:45:16 UTC 2021
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?
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
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.
> devel mailing list
> devel at rtems.org
More information about the devel