| commit | 3ad8e4b09fb8374a69988abbe5c683bb4ceebad9 | [log] [tgz] |
|---|---|---|
| author | Janet Adkins <janeta@us.ibm.com> | Wed Nov 20 14:34:20 2024 -0600 |
| committer | Patrick Williams <patrick@stwcx.xyz> | Mon Jan 27 17:12:03 2025 +0000 |
| tree | dc00b37a95a47da18594120370a6b6e340bdb598 | |
| parent | 4c549f63e1033b5ee47c54f1a80d060f15133b72 [diff] |
Add new interface to define sensor purpose A chassis can have a sensor which tracks the total power consumption. Clients such as bmcweb need a programmatic approach to finding the unique sensor from the chassis. A design discussion [1] in development channel of Discord settled on the following approach: - Define a D-Bus interface for defining a special purpose for a sensor. - Use the existing all_sensors/chassis association to connect the sensor to its Chassis. - Clients such as bmcweb use object mapper to find all_sensors associated with the Chassis. They then filter to find the sensor implementing the specific purpose required. This initial implementation only defines a single special purpose. The expectation is others will be added as needed in the future. The openpower-occ-control repo implemented a total_power association.[2] This will be modified to implement this new interface on the total_power sensor. There is a commit for bmcweb which will be modified to use this new approach for finding the total_power sensor.[3] Note: There is technical debt to convert all_sensors/chassis associations to use the monitoring/monitored_by association instead.[4] That change would also need to convert the association used to find objects implementing this interface. [1] https://discord.com/channels/775381525260664832/867820390406422538/1326612654852280433 [2] https://gerrit.openbmc.org/c/openbmc/openpower-occ-control/+/75572 [3] https://gerrit.openbmc.org/c/openbmc/bmcweb/+/57717 [4] https://discord.com/channels/775381525260664832/867820390406422538/1326609419022372916 Change-Id: Ic8b509c9b2b17e823243f7b784ef941ec461cddb Signed-off-by: Janet Adkins <janeta@us.ibm.com>
YAML descriptors of standard D-Bus interfaces. The format is described by the sdbusplus binding generation tool sdbus++.
Before defining a new D-Bus interface or modifying an existing one, please read through the documented set of the common requirements and expectations.
This project can be built with meson. The typical meson workflow is: meson builddir && ninja -C builddir.
The meson files used to handle the YAML files are automatically generated and found under the gen subdirectory. When adding or removing YAML files, this must be regenerated. This can be done with the helper script found in the gen subdirectory: cd gen && ./regenerate-meson.
Only the xyz/openbmc_project and org/freedesktop interfaces are built by default. Other interfaces can be enabled by meson options:
-Ddata_com_ibm=true-Ddata_org_open_power=trueExample: meson builddir -Ddata_com_ibm=true && ninja -C builddir