openbmc/entity-manager/CONFIG_FORMAT.md

12    - Configuration files will get replicated and built to support hundreds of
14      contrast, reactors tend to scale as a logarithm of system count, with each
15      new system supported adding fewer and fewer reactors. As such, pushing the
18    - Reactor writers tend to be domain experts on their subsystem, and
28    - Hardware constraints, bugs, and oddities are generally found over time. The
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
51      simplicity, or based on a greater understanding of the system level
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
74 In most cases a server system is built with multiple hardware modules (circuit
75 boards) such as baseboard, risers, and hot-swap backplanes. While it is
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 |
92 | "Bind\*"      | `"2U System Fan connector 1"`                                       | The record isn't complete and needs to be combined with another to be functional. The value is a unique reference to a record elsewhere.                                                                                                                                                                      |
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
121 make up a complete system. An example baseboard JSON file shown below defines
130       "Name": "1U System Fan connector 1",
137       "Name": "2U System Fan connector 1",
213 [Full Configuration](https://github.com/openbmc/entity-manager/blob/master/configurations/WFT_Baseboard.json)
215 ## Configuration Records - Chassis Example
221 System Fan connector 1". When the probe command finds the correct product name
229       "BindConnector": "1U System Fan connector 1",
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