Brad Bishop | ada40c5 | 2020-05-07 19:32:05 -0400 | [diff] [blame] | 1 | Entity manager configuration file schema |
| 2 | ---------------------------------------- |
| 3 | |
| 4 | Entity manager configuration files are JSON documents and can be validated with |
| 5 | a JSON schema[1]. This document provides an overview of the general structure |
| 6 | of an entity manager configuration file. |
| 7 | |
| 8 | An entity manager configuration file consists of one or more entity manager |
| 9 | configurations. This provides flexibility for system designers - the |
| 10 | configuration data for an entire platform or set of platforms can be expressed |
| 11 | in a single file, or can be organized into several smaller files. Thus, the |
| 12 | top most schema describes a single object or an array of objects. |
| 13 | |
| 14 | A single entity manager configuration |
| 15 | ---------------------------------------- |
| 16 | At its core entity manager simply exports objects onto DBus when a specific |
| 17 | event occurs. As such, an entity manager configuration provides a syntax for |
| 18 | describing the dbus interfaces to export, the object paths on which to add the |
| 19 | interfaces and the event that should trigger the export. This is accomplished |
| 20 | with four properties. |
| 21 | |
| 22 | Type |
| 23 | ---------------------------------------- |
| 24 | The type property identifies the type of the configuration. When exported, |
| 25 | configuration data will be instantiated as grandchildren of |
| 26 | /xyz/openbmc_project/inventory/system/<Type>. For a comprehensive list of |
| 27 | supported types, consult the schema (global.json). |
| 28 | |
| 29 | Name |
| 30 | ---------------------------------------- |
| 31 | The name property identifies the name of the configuration. When exported, |
| 32 | configuration data will be instantiated as children of |
| 33 | /xyz/openbmc_project/inventory/system/<Type>/<Name>. Additionally, any DBus |
| 34 | interfaces listed in openbmc-dbus.json will be added on |
| 35 | /xyz/openbmc_project/inventory/system/<Type>/<Name>. |
| 36 | |
| 37 | Probe |
| 38 | ---------------------------------------- |
| 39 | The probe property describes the event which will cause entity manager to |
| 40 | export the configuration to DBus, making it available to other applications. |
| 41 | |
| 42 | Exposes |
| 43 | ---------------------------------------- |
| 44 | The exposes property describes the configuration data at its most specific |
| 45 | level. The exposes property is an array of heterogeneous configuration data. |
| 46 | Each exposes element has its own schema which is outlined by the subschemas in |
| 47 | the schemas directory. Each schema must require a type and name (not to be |
| 48 | confused with the Type and Name properties of the parent JSON object) property |
| 49 | since entity manager will construct the Dbus interface name and object path |
| 50 | based on those properties: |
| 51 | |
| 52 | /xyz/openbmc_project/inventory/system/Board/RiserCard1/<Name>: |
| 53 | xyz.openbmc_project.Configuration.<Type>: |
| 54 | <remaining properties defined by exposes subschema> |
| 55 | |
| 56 | Adding new exposes property subschema |
| 57 | ---------------------------------------- |
| 58 | New subschema for the exposes property must be added to the schema directory, |
| 59 | and then referenced from global.json at /definitions/EMExposesElement. Exposes |
| 60 | element subschema must require a type and name property (the validator will |
| 61 | fail otherwise) and should explicitly enumerate all properties and use |
| 62 | additionalProperties so mistakes can be found |
| 63 | during validation. |
| 64 | |
| 65 | Adding new Dbus interfaces |
| 66 | ---------------------------------------- |
| 67 | To export new interfaces on the configuration parent object e.g.: |
| 68 | /xyz/openbmc_project/inventory/system/Board/RiserCard1 add additional subschema |
| 69 | to openbmc-dbus.json. |
| 70 | |
| 71 | [1] https://json-schema.org/ |