Proposal to change sensor interface to use double values

Patrick Venture venture at google.com
Tue Aug 7 06:08:31 AEST 2018


On Mon, Aug 6, 2018 at 12:10 PM, James Feist
<james.feist at linux.intel.com> wrote:
> I've submitted a change to modify the sensor interface to remove scale, and
> make the sensor value a double. The main reason for doing this is
> simplification of the interface. In most usages, daemons pull the value, and
> the scale, then immediately translate this value to a double. This could
> easily be done once by the sensor producer instead of all daemons. The
> counter example that was given was phosphor-fan-presence, but doing a quick
> grep I can't find scale being used, so this might mean for a scaled fan you
> have to factor that in to all configuration files, or scaled fans aren't
> supported. The threshold interface is not usable independent from the value
> interface, as the thresholds are affected by the same scale. Using a fixed
> scale also won't work well for a logarithmic sensor, while floating point
> would. Realistic precision should not be affected for any common sensor. We
> also in the future may be interested in a daemon producing a threshold for a
> sensor that another daemon owns. With the scale existing elsewhere, this
> would not be trivial to map.
>
> Review for context: https://gerrit.openbmc-project.xyz/#/c/11739/
>
> This change is not ready to be submitted as is, but we would like to hear if
> there are any major objections. If not, we would like to start an upgrade
> path to support both interfaces until it is possible to make the switch.
> Bmcweb already supports both. In most cases this is just pulling the value
> using a visitor, and setting the scale to 0 if it does not exist. Max and
> Min can also be used for IPMI scaling.

I'm fine with this.  It saves everybody converting it to a double
before using.  Further scaling, which can be necessary can be further
done against the double.  For instance, with ipmi, to fit a value we
sometimes scale again.

>
> Thanks,
>
> - James Feist
>
>


More information about the openbmc mailing list