openbmc/entity-manager/CONFIG_FORMAT.md

12    - Configuration files will get replicated and built to support hundreds of
13      systems over time, and scale linearly with the number of systems. In
18    - Reactor writers tend to be domain experts on their subsystem, and
28    - Hardware constraints, bugs, and oddities are generally found over time. The
29      initial commit of a configuration file is far from the final time that
33    - Having separate config files reduces the number of platforms that need to
37    - Having one config file per piece of hardware makes it much easier and clear
39    - Note: This is a "guideline" not a "rule". There are many cases of hardware
42      - Example: SAS modules and cards made by the same company, on the same
44      - Non-Example: Power supplies. While all pmbus power supplies appear
49 3. Configuration files are not a long-term stable ABI. Why?
50    - Configuration files occasionally need to modify their schema in pursuit of
53    - The repo will ensure that all schema changes are enacted such that the
57    - Note: This drives the requirement that config files shall not be checked
62    - There are many behaviors that the BMC has that are very easily detected at
66      platforms, and doesn't need to be an entity-configurable parameter. In
75 boards) such as baseboard, risers, and hot-swap backplanes. While it is
81 power supplies, fans, and PCIe add in cards.
87 | :------------ | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
89 | "Probe"       | `"xyz.openbmc_project.FruDevice({'BOARD_PRODUCT_NAME':'FFPANEL'})"` | Statement which attempts to read from d-bus. The result determines if a configuration record should be applied. The value for probe can be set to “TRUE” in the case the record should always be applied, or set to more complex lookups, for instance a field in a FRU file that is exposed by the frudevice |
99 | :-------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
101 | "$address"      | When the "probe" is successful, this template string is substituted with the (7-bit) I2C address of the FRU device.                                                                                                                 |
102 | "$index"        | A run-tim enumeration. This template string is substituted with a unique index value when the "probe" command is successful. This allows multiple identical devices (e.g., HSBPs) to exist in a system but each with a unique name. |
118 ## Configuration Records - Baseboard Example
213 [Full Configuration](https://github.com/openbmc/entity-manager/blob/master/configurations/WFT_Baseboard.json)
215 ## Configuration Records - Chassis Example
256 The entity-manager can key off of different types and export devices for
260 ## C-Style Comments Support
262 The configuration JSON file supports c-style comments base on the rules as
265 - Single-line style comments (//) can be on a new line or at the end of a line
270   // Single-line style comment (new line)
271   Key: "Value", // Single-line comment (end of content)
275 - Multi-line style comments (/\* \*/) use the must be free-standing.
279   /* Multi-line style comment */
281    * Multi-line style comments
286 - When running autojson.py on a configuration JSON file, the comments will be
291 - No attempts to re-indent multi-line comments will be made.
294 prettier before using this script and planning to move multi-line comments