[PATCH] Add configuration option for single processor applications

[Richi Dubey]

>
> 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 understand, Thanks for the clarification.

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.

Got it. Thanks!



On Mon, Mar 22, 2021 at 11:08 PM Gedare Bloom <gedare at rtems.org> wrote:

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