> -----Original Message----- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of > Honnappa Nagarahalli > Sent: Tuesday, May 02, 2017 12:03 AM > To: Bill Fischofer <bill.fischo...@linaro.org> > Cc: lng-odp-forward <lng-odp@lists.linaro.org> > Subject: Re: [lng-odp] Modular queue interface > > On 1 May 2017 at 12:58, Bill Fischofer <bill.fischo...@linaro.org> wrote: > > > > > > On Sun, Apr 30, 2017 at 11:05 PM, Honnappa Nagarahalli > > <honnappa.nagaraha...@linaro.org> wrote: > >> > >> We talked about introducing the modular queue interface. I spent time > >> re-looking at this, according to me it does not solve any issues we > >> have currently. > >> > >> The main issue we are trying to address currently is avoiding code > >> under #ifdefs and the resulting compilation combinations and testing > >> those code paths. > >> > >> Currently, we have 3 schedulers - default, SP and iQuery - To use any > >> of these, ODP needs to be configured with --enable-xxx option which in > >> turn defines the compile time #defines. The current code base has code > >> under these flags. Modular queue interface does not change any of > >> this. > > > > > > The key is that these #ifdefs exist only within the scheduler framework > > itself (odp_schedule_if.c). The scalable scheduler should follow the > same > > model. > > Keeping #ifdefs to this file alone does not solve the CI and testing > problems. We still end up having multiple code paths.
The only #ifdef used today is the built time selection of the scheduler (tie callbacks to the right scheduler implementation) ... and that could be done at runtime as easily. The big thing is that all code of all three schedulers are built in any case. So, as soon as someone e.g. changes any internal interface any of these schedulers use - the build breaks (no matter which scheduler was selected in .configure). That does not happen when code is #ifdef'd away. > >> I do not think there is a need to introduce a modular queue interface > >> at this time. There has been always problems when modularity has been broken. Proper use of internal (conversion, etc) interfaces is the way to keep (at least some) sanity in the code base. One module should assume as little as possible about implementation details of another module (e.g. if a handle of the other module is a pointer or an index). -Petri
