commit | 13e03339543cdc2b6740ed20064fbedd3252d2c9 | [log] [tgz] |
---|---|---|
author | Shawn McCarney <shawnmm@us.ibm.com> | Tue Aug 25 18:27:07 2020 -0500 |
committer | Shawn McCarney <shawnmm@us.ibm.com> | Tue Aug 25 18:27:07 2020 -0500 |
tree | 154838aa06a0b7b521794d881dbfda7b071208c8 | |
parent | 93ee416a215a0f13e310a0b785b81a24fd08fb1a [diff] |
cold_redundancy: Fix build failures The cold_redundancy application began failing to build recently due to missing boost::asio includes. I believe the cause is a change to some sdbusplus header files. The sdbusplus header files previously included the convenience header file "boost/asio.hpp". However, the sdbusplus header files now include more specific boost header files. See https://github.com/openbmc/sdbusplus/commit/38ab5ecfe3c51501a9380e2c30dbb5fdd88cf4f9 for more information. The cold_redundancy source files appeared to have been relying on sdbusplus to include the convenience header. They do not include header files for some of the boost asio classes they are using. I did not write any of the cold_redundancy application and do not have the ability to test it. For this reason, I made the simple change of adding an include of "boost/asio.hpp" to the cold_redundancy header file that needed it. This would seem to be a safe change, since it effectively 'undoes' the change made in sdbusplus. The maintainers of this application may wish to push up another commit that replaces this with more specific includes. Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I42154d621fcf125f95a639375d3749dbd7dcd91d
This repository contains applications for configuring and monitoring devices that deliver power to the system.
To build all applications in this repository:
meson build ninja -C build
To clean the repository and remove all build output:
rm -rf build
You can specify meson options to customize the build process. For example, you can specify:
Several applications in this repository require a PSU JSON config to run. The JSON config file provides information for:
There is an example psu.json to describe the necessary configurations.
inventoryPMBusAccessType
defines the pmbus access type, which tells the service which sysfs type to use to read the attributes. The possible values are:/sys/bus/i2c/devices/3-0069/
/sys/bus/i2c/devices/3-0069/hwmon/hwmonX/
/sys/kernel/debug/pmbus/hwmonX/
/sys/kernel/debug/pmbus/hwmonX/cffps1/
fruConfigs
defines the mapping between the attribute file and the FRU inventory interface and property. The configuration example below indicates that the service will read part_number
attribute file from a directory specified by the above pmbus access type, and assign to PartNumber
property in xyz.openbmc_project.Inventory.Decorator.Asset
interface."fruConfigs": [ { "propertyName": "PartNumber", "fileName": "part_number", "interface": "xyz.openbmc_project.Inventory.Decorator.Asset" } ]
psuDevices
defines the kernel device dir for each PSU in inventory. The configuration example below indicates that powersupply0
's device is located in /sys/bus/i2c/devices/3-0069
."psuDevices": { "/xyz/openbmc_project/inventory/system/chassis/motherboard/powersupply0" : "/sys/bus/i2c/devices/3-0069", }