| commit | 9b4a20e98350fea216aca1aa2af99477987548a4 | [log] [tgz] |
|---|---|---|
| author | Ed Tanous <edtanous@google.com> | Tue Sep 06 08:47:11 2022 -0700 |
| committer | Ed Tanous <ed@tanous.net> | Fri Sep 16 18:54:39 2022 +0000 |
| tree | 88efa7323536070e47edfcc942ba18de01c87637 | |
| parent | e330c0c1feedc765f8bef3fc0215c764e43bfc5c [diff] |
Move to steady_timer deadline_timer and steady_timer have one important difference, the former runs off CLOCK_REALTIME, and the later runs off CLOCK_MONOTONIC. For a long time we've relied on deadline_timer incorrectly, given that dbus-sensors does not care in the least about the calendar time, and only cares about the difference between sensor scans. Fortunately, this likely has no effect on the behavior of the sensors most of the time, and in general, in a time change, the clock generally moves forward, so all timers would immediately expire, scan all sensors, and move on. phosphor-pid-control is intentionally designed to handle this case, so it's quite likely that a user would never notice it, and even if they did, would have to be looking at a debug console the moment it happened. The other effect is that in most cases, sensors call clock_gettime more than they probably need to, which might slow down the performance. This commit moves all usages of sensor timing to steady_timer, which should give us more consistent results, and (in theory at least) be faster. Because of stdlib compliance things, this also has the effect of us dropping our dependence on boost::posix_time, and move to std::chrono::duration objects, per the coding standard. Signed-off-by: Ed Tanous <edtanous@google.com> Change-Id: I69f948fb3f0fc0dfd7fd196d26ba46742a3e15a7
dbus-sensors is a collection of sensor applications that provide the xyz.openbmc_project.Sensor collection of interfaces. They read sensor values from hwmon, d-bus, or direct driver access to provide readings. Some advance non-sensor features such as fan presence, pwm control, and automatic cpu detection (x86) are also supported.
runtime re-configurable from d-bus (entity-manager or the like)
isolated: each sensor type is isolated into its own daemon, so a bug in one sensor is unlikely to affect another, and single sensor modifications are possible
async single-threaded: uses sdbusplus/asio bindings
multiple data inputs: hwmon, d-bus, direct driver access
A typical dbus-sensors object support the following dbus interfaces:
Path /xyz/openbmc_project/sensors/<type>/<sensor_name>
Interfaces xyz.openbmc_project.Sensor.Value
xyz.openbmc_project.Sensor.Threshold.Critical
xyz.openbmc_project.Sensor.Threshold.Warning
xyz.openbmc_project.State.Decorator.Availability
xyz.openbmc_project.State.Decorator.OperationalStatus
xyz.openbmc_project.Association.Definitions
Sensor interfaces collection are described here.
Consumer examples of these interfaces are Redfish, Phosphor-Pid-Control, IPMI SDR.
dbus-sensor daemons are reactors that dynamically create and update sensors configuration when system configuration gets updated.
Using asio timers and async calls, dbus-sensor daemons read sensor values and check thresholds periodically. PropertiesChanged signals will be broadcasted for other services to consume when value or threshold status change. OperationStatus is set to false if the sensor is determined to be faulty.
A simple sensor example can be found here.
Sensor devices are described using Exposes records in configuration file. Name and Type fields are required. Different sensor types have different fields. Refer to entity manager schema for complete list.