> > 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 <ged...@rtems.org> wrote: > 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
