RFC: multiple system configurations in a single image

[Tanous, Ed]

Thanks for bringing this up Brad.  I was planning on sending this out after the technical call, but you beat me to it.  You did a great job summarizing our main points.

One key takeaway from this is the end goal that's driving our desires:  Platform ports should take a single developer less than a week to accomplish, and have a high (90%+) reliability of being functionally correct.  With all 
	
> Extra pro: you can edit it at run-time and relaunch the application :)
This is exactly our use case we wanted to outline with the patch.  Consumers of the platform may choose to change parameters at runtime (manufacturer ID or platform ID are good examples in the patch, fan control tuning is an example not in the patch).  Lots of customers require runtime configurability without recompiling, as uploading an unsupported image would void warranties for production commercially supported platforms from most manufacturers.  Also, making this runtime configurable is a huge win for the end user that doesn't necessarily have the expertise to execute a yocto build and sign it appropriately.

> > not-so-good:
> >   - complexity shift from build to runtime (parsing, validation)
In our experience with other BMC codebases, this complexity shift leads to a very clear distinction on what is supported by the runtime and provides a clear distinction between the "core" (code running that's common) and the "platform" (the data that's driving it).
The Facebook openbmc implementation has a very similar structure for JSON based runtime configurability separated from the core but does it in multiple files.  An example of fan control is here:
https://github.com/facebook/openbmc/blob/helium/meta-facebook/meta-fbtp/recipes-fbtp/fscd/fscd/fsc-config.json 
It does not take the "single file" approach, but in discussions with Sai, they were open to moving that direction.

> There is a downside to delayed validation, however, the parsing is a "one-
> time" start-up cost for the applications.  Also, it might be cleaner in terms of
> one system file describing everything that all the different daemons can
> parse... there are certainly a few different approaches to this.
I could not have said it better myself.  The "one file" approach is exactly the direction we would like to take, but wanted some precedence for runtime-configured platforms before we tilted at that windmill.

> >   - loss of implementation freedom of choice (adopting the proposed
> > solution _requires_ json parsing on _all_ platforms using reference
> > applications, even platforms using single configuration images)
I find this hit on complexity to be fairly minimal for most applications, as python has "batteries included" bindings for json parsing, and C++ has several mature libraries to select from.  The get device id example we pushed used nlohmann json, as that seemed to have the easiest to use abstraction, but we've also shipped platforms with cjson in the past.

> Previously for the most part, we all had to do yaml->cpp, which certainly had
> its own drawbacks.  I think json will provide a cleaner mechanism for
> backwards compatibility.  Every platform wont' need to regularly update their
> configuration files unless there's a breaking change.	
This is exactly our experience.  In other platforms, running off configuration files allowed us to completely rewrite internal implementations (sometimes changing languages) with negligible user impact.