Thank you. I was asking to get a grip on how a platform should behave.
I'll prepare an RFC with code examples and meanwhile I'll just stick to
getenv().
Best Regards,
Stanislaw Kardach
On 01/17/2017 04:25 PM, Maxim Uvarov wrote:
We discussed that question on yesterday meeting call. And decision was
to stay with current approach. If some platform needs additional
settings they can be provided with getenv() or config, or shared memory
setting, or any other way which system allows.
But you also can came with some rfc patch which will be more easy to
discuss, maybe we do not see something from description...
Best regards,
Maxim.
On 01/17/17 18:00, Mike Holmes wrote:
On 16 January 2017 at 05:33, Stanislaw Kardach <k...@semihalf.com> wrote:
Hi all,
I am working on a platform that may have mandatory parameters for a
correct initialization (and also unique to each ODP instance). If I'm
reading it right the call to odp_init_global() may take NULL for
platform_params and then platform is supposed to "set all parameters to
their defaults". In an old mail chain (see [1]) on the list I've seen that
this "defaults" may mean another means of transport (i.e. environment
variables) for the platform parameters.
Is it allowed for a platform to fail odp_init_global() if it did not
receive a platform parameter required for its startup (i.e. some crucial
device that is distributed on per instance basis)? I guess this boils down
to whether "mandatory" platform parameters are allowed or not?
Any platform mandatory parameter makes the application non portable, it
will not pass the test suite without wrappers for every test that pass the
new arguments.
So the implimentation can fail if soemthign is missing in the platform
args, but then that platform is not compliant becasue the apps need to know
platform specifics.
Short answer they are not allowed to be mandatory if you want to be
complaint, but there are likely use cases where that may be ok as no high
portability is desired.
To be portable these args have to be abstracted to the the param struct
and not the platform_params to be rational for all users.
If yes, then aren't allowing applications to pass NULL in
odp_init_global() is only masking the problem as each ODP implementation
that has such mandatory parameters will need to provide an alternative
means of transport for the examples, tests and probably "platform
independent" applications to run and the only place where this is specified
is platform documentation?
I was wondering whether it may make sense to work on a platform
independent API for parsing such parameters from an argv+argc set or a
key=value list/array that would allow platform to go through parameters
from command line and report error if it is missing mandatory parameters
(and it did not get them through other transport means)?
If not then, given that default initialization turns out to be not
possible, when and how should I report to the user that he's missing some
parameters? During odp_init_global()?
I think the idea of a config file that can be loaded by global init that
describes the platfrom was passed around as a possible solution, agree that
if you now have a real use case it is a good topic to look at.
[1] https://lists.linaro.org/pipermail/lng-odp/2015-November/017486.html
--
Best Regards,
Stanislaw Kardach
