On 26/11/15 09:25, Savolainen, Petri (Nokia - FI/Espoo) wrote:
-----Original Message-----
From: EXT Zoltan Kiss [mailto:[email protected]]
Sent: Tuesday, November 24, 2015 4:45 PM
To: [email protected]
Cc: [email protected]; Savolainen, Petri (Nokia - FI/Espoo);
[email protected]
Subject: Re: [API-NEXT PATCH] api: init: allow implementation to use
private ways for its own configuration
Could anyone review this? Petri?
On 18/11/15 16:22, Zoltan Kiss wrote:
This could help the existing configuration methods to be used if the
application prefers that. The platform_params should always supersede
that
though.
Signed-off-by: Zoltan Kiss <[email protected]>
diff --git a/include/odp/api/init.h b/include/odp/api/init.h
index 737ff6d..24f4f3a 100644
--- a/include/odp/api/init.h
+++ b/include/odp/api/init.h
@@ -141,6 +141,9 @@ typedef struct odp_platform_init_t {
*
* This function must be called once before calling any other ODP API
* functions.
+ * The underlying implementation may have another way to get
configuration
+ * related to platform_params (e.g. environmental variable,
configuration
+ * file), but if the application passes it, it should always supersede.
*
* @param params Those parameters that are interpreted by the
ODP API.
* Use NULL to set all parameters to their
defaults.
Which configuration should supersede which?
"but if the application passes it, it should always supersede."
As this is in the comment of odp_platform_init_t, sed
s/"it"/"odp_platform_init_t"/g
Isn't it that way around that config files and env params are usually used to
override the hard coded configuration. So, you'd build your application with a
default config, but would use extra methods to override the hard coded default
config. If hard coded config all ways overrides, you cannot try other configs
without rebuilding (which may not be even possible if you just have received
the app binary).
Yes, but noone talks about hardcoded configuration here. Every sensible
application should have a sensible way to get configured, including ODP
platform parameters of the user's choice to be passed to the actual
platform. Of course the application can choose to detect the platform
runtime and apply a default if nothing else configured to it, but it
would be still more relevant than some platform defaults.
It may vary per parameter and application, which parameters are possible to
override (without application 100% controlling it).
I'm not sure I understand that. A parameter is something which is
configurable, by definition. In other words, it's possible to override
it. "always supersede" implies to me that, but you can suggest a better
phrasing.
Can we say anything else than platform configuration is platform specific
Even platform config is platform specific, it also seems obvious to me.
and may include usage of platform_params ?
My aim here is that if the app provide platform_params, then the
platform MUST use that instead of other possible configuration ways (if
any). So the application can enforce (if it wants) config, which is
probably coming from the user through some way of app configuration.
-Petri
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
