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 <ged...@rtems.org> wrote: > Hi Richi, > > On Wed, Mar 17, 2021 at 1:06 PM Sebastian Huber > <sebastian.hu...@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@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
