On Sun, Mar 21, 2021 at 11:48 PM Richi Dubey <richidu...@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 <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