| # dbus usage | |
| The following are guidelines for bmcweb's use of DBus to construct Redfish | |
| schemas: | |
| - Do not require (ie set 500 internal error on) an implementation present a | |
| property that wasn't in the first commit of the interface unless it can be | |
| verified that _all_ OpenBMC implementers of the interface support that | |
| property. | |
| - If an implementation presents a property that doesn't match the type specified | |
| by the interface at any version, it shall be repored as a 500 error. | |
| - If the DBus interface definition has an "unknown" or "unspecified" value, | |
| detecting these will omit the property from the Redfish tree, in line with the | |
| Redfish specification. | |
| - All DBus interfaces on all object paths are optional. An object missing an | |
| interface is never an error, and shall simply omit the relevant properties | |
| and/or actions from that Redfish Resource. | |
| - bmcweb will code to the DBus interface itself. This means that daemons are | |
| expected to handle functionally bad, but DBus-correct input in their own | |
| process, and return appropriate return codes. This is done to reduce the | |
| duplication in input processing between the various user-facing daemons. | |
| - There are interfaces for which there is an expectation that there will only | |
| ever be one producer in the project (ex bmc networking, user management). In | |
| these cases, it is desirable to call the daemon by well known name directly. | |
| Bmcweb APIs should call the mapper in cases where it's reasonably expected | |
| that multiple implementations exist (ex, CPU management, Sensors). |