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

José Alamos notifications at github.com
Wed Jan 2 14:02:31 CET 2019

jia200x commented on this pull request.

> +and the following acronyms:
+- RDM: RIOT Developer Memo
+- CTF: RIOT's Configuration Task Force
+- RCS: Runtime Configuration System
+# 1. Introduction
+This document specifies the proposed architecture by the
+Configuration Task Force (CFT) to implement a secure and reliable Runtime
+Configuration System (RCS), focusing in modularity, reusing of existing
+technologies in RIOT (network stack, storage interface) and adhering to
+# 2. Architecture
+The RCS is formed by [the RIOT Registry](3-the-riot-registry), one or more [Registry Handlers](4-registry-handlers), one or more
+[storage facilities](5-storage-facilities) and a [configuration manager](6-configuration-manager) with one or more interfaces. The

> Could you add a bit more explanation here? Commonly, an architecture consists of components, their semantics, their interfaces, and their interactions. I would love to see an exhaustive high-level description here. In particular, I haven't really caught:

Sure, we will.

I will try to answer here anyway and rephrase this section on the fly.

> Is the registry just a facade or does it provide intrinsic functionality?

The registry provides intrinsic functionality:
- Register and keep a list of _registry handlers_
- Orchestrate config operations via these _registry handlers_ (get, set, commit, export)

> Is the Registry an order-preserving key-value store of contextually grouped keys?

I would say the Registry is an _orchestrator_ to configure RIOT modules at runtime (via _registry handlers_) and persist these configurations in any data structures like file systems (via _storage_).

The combination of the Registry + Registry Handlers + Storage Facilities provide a key-value store of contextually grouped keys (ordered or non-ordered) at code level. Then, a Configuration Manager is required e.g to configure a TX interval via CoAP.

> What is the API of the Registry in relation to the APIs of the Registry Handlers?

The API of the Registry provides high level functions to handle persistent configurations. The API of the Registry Handlers provides low level functions that are intended to be orchestrated by the Registry.

In RIOT slang, the Registry is to `netapi` as the Registry Handlers are to `netdev`.

> Is the configuration manager actively handling system configurations? Or is it just a skeleton for orchestrating the access to the configuration system?

As described before, it's closer to a skeleton for orchestrating the access to the configuration system.

> What does a Registry Handler do beyond providing a contextual name?

A Registry Handler also provides 4 functions required to do all configuration operations, as described in [4. Registry Handlers](https://github.com/RIOT-OS/RIOT/pull/10622/files#diff-63356eb67626b5872bf0edb05a1a0befR77). [Here's a conceptual example of how a registry handler would look](https://gist.github.com/jia200x/cca922092ca0d13957dee203e9ad9b55)

> How do all these components interact when retrieving or changing a configuration parameter?

E.g for retrieving the value of "a_config" (uint16_t) from a module "module" in a "buf" variable, a user would do:
registry_get_value("module/a_config", buf, sizeof(uint16_t));
1. Searches for a Registry Handler with "module" name in the global list of registry handlers.
2. If found, calls the registry handler's `get` function with "a_config" key.
3. The `get` function copies the value to the `buf` variable

E.g for changing a configuration parameter:
/* Set "a_config" to the value in buf */
registry_set_value("module/a_config", buf);
1. Searches for a Registry Handler with "module" name in the global list of registry handlers.
2. If found, calls the registry handler's `set` function with "a_config" key.
3. The `set` function copies the value in the `buf` variable to the corresponding variable.

At any time it's possible to either load or save all configuration parameters from the non-volatile storage device with dedicated load and save functions.
/* At this point all configuration have their default values */


/* Now, all configurations got their values from the non-volatile storage */

registry_set_value("module/a_config", buf, sizeof(uint16_t));

/* At this point "a_config" has a different value BUT STILL NOT REFLECTED IN THE STORAGE


/* Now, the new configuration is stored permanently */

As one could imagine, `registry_load` will read all configurations from the storage and call all registry handler `set` functions . And of course, `registry_save` will call all registry handler `get` functions and save them in the storage.

Hope everything is more clear now. I will reflect these answers in the RDM. Please don't hesitate to ask again if needed.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190102/2c98a209/attachment-0001.html>

More information about the notifications mailing list