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