article on data in OpenBMC

[Vijay Khemka]

On 5/28/20, 5:43 AM, "Brad Bishop" <bradleyb at fuzziesquirrel.com> wrote:

    On Tue, 2020-05-26 at 18:10 +0000, Vijay Khemka wrote:
    > 
    > On 5/26/20, 8:57 AM, "openbmc on behalf of Andrew Geissler" <
    > openbmc-bounces+vijaykhemka=fb.com at lists.ozlabs.org on behalf of 
    > geissonator at gmail.com> wrote:
    > 
    >   
    >     Not sure if this doc is the best place but I’d like to see a best
    > practices on
    >     file format (i.e. use .json) and runtime config file locations
    > (i.?e.? /etc/ /var type 
    >     decisions). Also, the recommendation to make your data runtime
    > config
    >     vs. build time config when possible (to make live debug/test
    > easier).
    > 
    > I agree with Andrew here. As not all data are under /etc, some of
    > runtime data are
    > under /var as well
    
    I do want to make a distinction between data that describes the
    properties of the system (e.g. things you'd find in a schematic) vs data
    generated by applications.  My intended audience was the people
    generating the former.  Any ideas on what an outline that maintains that
    distinction and includes application generated data would look like?
    
    >  so it would nice to have some policy defined what type can go
    > where.
    
    Yeah, this is definitely something I've been wanting to cover.  Any
    ideas on how to make this easy for someone to do?  For example we have
    the anti-patterns document with a template - if we have a similar best-
    practices document with a template would that help?  I'm not so sure
    because the anti-patterns document hasn't gotten much traction
    unfortunately...
We can have a separate document or section in a document which will talk
about runtime configuration data type and its targeted location. Infact we 
can have a predefined variable for these like $systemdir. And meson will have
definition of these data input. We can also give example of meson file as how
it will be included for any project.