[riot-notifications] [RIOT-OS/RIOT] doc/memos: RDM Runtime Configuration Architecture (#10622)

José Alamos notifications at github.com
Wed Jan 9 11:07:59 CET 2019


jia200x commented on this pull request.



> +
+A runtime configuration system is in charge of providing a mechanism to set and
+get the values of configuration parameters that are used during the execution
+of the firmware, as well as a way to persist these values. Runtime
+configurations are deployment-specific and can be changed on a per node basis.
+Appropriate management tools could also enable the configuration of node
+groups.
+
+Examples of runtime configurations are:
+- Transmission duty cycles
+- Sensor thresholds
+- Security credentials
+- System state variables
+
+These parameters might have constraints, like a specific order to be applied
+(due to interdependencies) or value boundaries.

Can you provide a concrete example where an application programmer exposes configuration parameters from other modules in this context?

E.g at RH `set` level, most of the times would look like:
```
/* Application RH */
set(key, value) {
    if(key == "foo")
        internal_static_variable = value;
}
```

If the module wants to change e.g AT86RF settings, it would need to add functions to expose static variables, which is non-sense IMO. If an application wants to expose these configs, it should expose "Application" and "AT86RF" Registry Handlers.

Do you think it's needed to state this? 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/10622#discussion_r246323289
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190109/ffb1aca0/attachment-0001.html>


More information about the notifications mailing list