I vote for B. The idea is that if the application wishes to override it can do so otherwise let the implementation take its defaults from the environment or however else it wishes to support platform-specific configuration options. This is in keeping with how we handle other overridable defaults for things like log and abort functions. Specify NULL == accept whatever default behavior is in effect, otherwise specify what you want. Simpler for everyone.
On Tue, Nov 17, 2015 at 1:05 PM, Mike Holmes <mike.hol...@linaro.org> wrote: > > > On 17 November 2015 at 13:54, Zoltan Kiss <zoltan.k...@linaro.org> wrote: > >> Hi all, >> >> Our odp_init_global() has a second parameter with type >> odp_platform_init_t. It's supposed to convey platform specific init >> parameters, however neither linux-generic nor linux-dpdk uses that. In the >> latter we use instead the ODP_PLATFORM_PARAMS environment variable. It has >> the little advantage that you don't have to modify your application's code, >> but it limits you to strings. In case of ODP-OVS we store this in OVSDB and >> retrieve it from the startup script (or specify it manually if you don't >> use the startup script.) >> I'm tempted to change ODP-OVS and ODP-DPDK to use odp_platform_init_t, >> would be cleaner for OVS and for any bigger application which have a nice, >> full-fledged config database solution. But that would immediately bring us >> a bigger problem: none of our unit tests or example applications supports >> passing this parameter at all. They are small applications, implementing a >> proper config management would be an overkill. I have two options to solve >> this: >> >> Apart from keeping the odp_platform_init_t type to be passed >> odp_init_global() >> >> A) change our code in linux-generic for examples and tests (>20 places in >> the repo) to get the platform parameters from ODP_PLATFORM_PARAMS env >> variable, and pass it down to odp_init_global() as a string. >> >> B) Or just allow a platform to use both ways, document this, and require >> that if both are present, the odp_platform_init_t passed as parameter >> should take precedence. So smaller applications using simply configurable >> platforms (like ODP-DPDK) don't have to figure out a way to deal with this >> problem. >> >> I have a slight preference towards B), but I could be convinced that it's >> a bad idea to have 2 ways to do the same thing. >> > > I like A, two ways always feels bad to me. > I like that it is explicitly passed in and you know what you have. Env > vars can change without the difference being seen in the code as easily and > not all OS'es have env vars. Env vars are a great way to do system > dependent things but I think the application should translate them into the > odp_platform_init_t so that the fudging is the apps problem and the app > knows more about the portability compromises it is making when using > platform specifics. > > >> >> Thoughts? >> >> Zoltan >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/lng-odp >> > > > > -- > Mike Holmes > Technical Manager - Linaro Networking Group > Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp > >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
