openbmc/entity-manager/CONFIG_FORMAT.md

13    - Configuration files will get replicated and built to support hundreds of
15      contrast, reactors tend to scale as a logarithm of system count, with each
16      new system supported adding fewer and fewer reactors. As such, pushing the
19    - Reactor writers tend to be domain experts on their subsystem, and
22      reactors on a single piece of hardware, and will generally have less
27    given piece of hardware in a single file, even at the risk of duplicating
30    - Hardware constraints, bugs, and oddities are generally found over time. The
35    - Having separate config files reduces the number of platforms that need to
39    - Having one config file per piece of hardware makes it much easier and clear
41    - Note: This is a "guideline" not a "rule". There are many cases of hardware
44      - Example: SAS modules and cards made by the same company, on the same
46      - Non-Example: Power supplies. While all pmbus power supplies appear
51 3. Configuration files are not a long-term stable ABI. Why?
53    - Configuration files occasionally need to modify their schema in pursuit of
54      simplicity, or based on a greater understanding of the system level
56    - The repo will ensure that all schema changes are enacted such that the
60    - Note: This drives the requirement that config files shall not be checked
65    - There are many behaviors that the BMC has that are very easily detected at
69      platforms, and doesn't need to be an entity-configurable parameter. In
77 In most cases a server system is built with multiple hardware modules (circuit
78 boards) such as baseboard, risers, and hot-swap backplanes. While it is
80 hardware modules into a single file if desired, it is recommended to divide them
90 …------------ | ------------------------------------------------------------------- | -------------…
92 …'BOARD_PRODUCT_NAME':'FFPANEL'})"` | Statement which attempts to read from d-bus. The result deter…
95 | "Bind\*"      | `"2U System Fan connector 1"`                                       | The record …
102 …-------------- | :--------------------------------------------------------------------------------…
104 …n the "probe" is successful, this template string is substituted with the (7-bit) I2C address of t…
105 …-tim enumeration. This template string is substituted with a unique index value when the "probe" c…
121 ## Configuration Records - Baseboard Example
124 make up a complete system. An example baseboard JSON file shown below defines
133       "Name": "1U System Fan connector 1",
140       "Name": "2U System Fan connector 1",
216 [Full Configuration](https://github.com/openbmc/entity-manager/blob/master/configurations/WFT_Baseb…
218 ## Configuration Records - Chassis Example
224 System Fan connector 1". When the probe command finds the correct product name
232       "BindConnector": "1U System Fan connector 1",
259 The entity-manager can key off of different types and export devices for
263 ## C-Style Comments Support
265 The configuration JSON file supports c-style comments base on the rules as
268 - Single-line style comments (//) can be on a new line or at the end of a line
273   // Single-line style comment (new line)
274   Key: "Value", // Single-line comment (end of content)
278 - Multi-line style comments (/\* \*/) use the must be free-standing.
282   /* Multi-line style comment */
284    * Multi-line style comments
289 - When running autojson.py on a configuration JSON file, the comments will be
294 - No attempts to re-indent multi-line comments will be made.
297 prettier before using this script and planning to move multi-line comments