topo_sensor_state_name() needs work
Libtopo implements an interface, topo_sensor_state_name(), which takes a sensor state value and returns a string containing a descriptive representation of the sensor state.
The primary consumers of this interface are fmtopo and hwgrok, both of which use it to provide a more human-readable representation of the sensor state.
There are two issues with how it's currently implemented:
1) It makes the assumption that only one discrete state will be asserted at any time. This is true for some sensors, but not all sensors.
2) Because it's working with a raw state value from IPMI, where certain reserved bits haven't been masked off, there no way for it to return a string to indicate the situation where no state are asserted (which is the normal state for many sensors). The facility/state property method should be masking off reserved bits - such that when no states are asserted, the state value is 0.
Updated by Rob Johnston 6 months ago
This change has already been integrated into illumos-joyent via the commit below:
commit 52767bdcffaf8c9d0a1cbfac8fa46b8506ee88cd Author: Rob Johnston <firstname.lastname@example.org> Date: Mon Mar 18 21:13:23 2019 +0000 OS-7241 topo_sensor_state_name() needs work Reviewed by: Robert Mustacchi <email@example.com> Approved by: Jordan Hendricks <firstname.lastname@example.org>
So this issue is simply to track getting the above change pushed upstream.
See the SmartOS ticket for details on how this change was tested:
Updated by Electric Monk 5 months ago
- Status changed from New to Closed
- % Done changed from 0 to 100
commit 881aaecd29563bc45bf78a3c8f1e534275021925 Author: Rob Johnston <email@example.com> Date: 2019-05-14T19:00:56.000Z 10897 topo_sensor_state_name() needs work Reviewed by: Robert Mustacchi <firstname.lastname@example.org> Reviewed by: Toomas Soome <email@example.com> Approved by: Gordon Ross <firstname.lastname@example.org>