On 1/29/16 6:25 PM, marko kiiskila wrote:
Hi all,
I was not happy with my first attempt at the interface between config and
subsystems.
So here’s a 2nd version.
The config items are still identified as strings.
Subsystem registers a set of handlers, and a root for it’s config tree.
struct conf_handler {
SLIST_ENTRY(conf_handler) ch_list;
char *ch_name;
char *(*ch_get)(int argc, char **argv, char *val, int val_len_max);
int (*ch_set)(int argc, char **argv, char *val);
int (*ch_commit)();
};
ch_name would be aforementioned root for subsystem config.
ch_get/ch_set do the obvious thing; get is for getting the current value, set
is used in setting a value.
Config items have names like subsystem/item1, or subsystem/item2/item3.
‘/‘ would be used as a delimiter between components of the name. This name gets
split into
components and gets passed in as argc/argv value to subsystem handler.
When a blob of configuration comes in, it would be translated into a bunch of
calls to set(),
followed by commit.
The idea is to have set() validate the input, stash the value, and then ‘apply’
it when commit
gets called.
As you can see, the value also is passed in a form of a string. There’s some
helper functions
that you can use to translate between string and integers and so forth. Use of
those is
optional, but probably a good idea.
There is still no persistent storage of config. We should have at least 2
options for this:
storage of config in files, or in a raw flash region (when FS is not available).
I’m thinking the API should be similar for both, so decision of which one to
use will be
a simple build time knob.
+1 to this.
How does configuration get registered with the system? i.e. If I
wanted to dump the current state of all configuration in the system, how
would that happen using the above APIs?
Should commit() have the notion of a commit ID + timestamp? That way
for a given set of variables, you can know when they were changed.
There was a request to be able to load configuration from multiple sources;
e.g. from
a number of files and from the flash variable as well.
Any system will have some config items that are going to be set at
manufacturing time
(serial numbers, for example) and then there will items that change more often.
So one could for example have the manufacturing config live somewhere else from
everything else. This way reverting back to manufacturing config should be easy.
+1
I think some thought needs to be put into how to manage a manufacturing
configuration, and the overlap between that and active configuration.
I don't know if folks on the list have thoughts on this.
Sterling
