Comments on Sensor design.

Patrick Williams patrick at stwcx.xyz
Wed Nov 2 06:24:09 AEDT 2016


On Tue, Nov 01, 2016 at 10:10:08AM -0400, Brad Bishop wrote:
> I can see a path here to extending what a sensor is (additional properties) 
> without impacting the existing API.  Do we lose that capability with option #1?
> What about com.ibm.Sensor or org.open_power.Sensor?

I don't think we lose that.  Someone could always extend it with a
'com.ibm.Sensor.Temperature' interface if they wanted.

I fully expect that we will have at least one extension which is related
to thresholds.
    xyz.openbmc_project.Sensor.Threshold
        property max
        property min

I suspect what I just wrote isn't correct and may require multiple
interfaces to handle all the different threshold types.

> > 
> > In both cases the dbus path could contain the 'type':
> >    /xyz/openbmc_project/sensors/temperature/ambient
> >    /xyz/openbmc_project/sensors/fan_tach/fan0
> > 
> > The question is essentially should the "Unit" property be used to
> > resolve the 'type' or should we have distinct interfaces for each
> > 'type’?
> 
> Leaning towards the latter, for the reason stated above.
> 

The big trade-off to me between them, besides minor impact of multiple
implementations of effectively the same content, has to do with signals
and filtering.  I could see it interesting to listen for signals on all
*.Sensor instead of having to listen for them each individually.  Maybe
the path is sufficient for this as well.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161101/4bec77d6/attachment.sig>


More information about the openbmc mailing list