Comments on Sensor design.

[Brad Bishop]

I have changed my mind.  I think I favor the single interface approach now, with sensor type expressed in the path hierarchy.  From an end user perspective, it makes sense to group all the temperature sensors here for example (this would be a REST collection):

/xyz/openbmc_project/sensors/temperature

The only other way to express the type outside the BMC (DBUS interfaces are not exposed) is with a property, but that requires a lot queries from a client or a fancy query mechanism like CIM has.  Given that I’m not seeing any motivation to have different interfaces per type or a property in a unified interface that denotes the type.

So I am proposing just a handful of interfaces for now, found here:

https://gerrit.openbmc-project.xyz/#/c/1106

This should give us enough definition and still be flexible.

Moving past the API definition…there is an unfinished hwmon monitoring application out there:
https://github.com/openbmc/phosphor-hwmon

My expectation is that this application will be started via udev+systemd and enter a polling loop with objects implementing the interfaces above, being created/updated on each poll.  This will generate a stream of dbus signals for the rest of the applications to listen to and act on.

This feels like a pretty general implementation for hwmon class sensors so it seems like a good candidate for the reference implementation.  In the longer term, I anticipate reference implementations for other, non-hwmon classes of sensors.

I’m sure I’ve probably missed something - please let me know.

thx - brad

> On Nov 6, 2016, at 10:54 PM, Patrick Williams <patrick at stwcx.xyz> wrote:
> 
> On Wed, Nov 02, 2016 at 10:12:47AM -0400, Brad Bishop wrote:
>> 
>>> On Nov 2, 2016, at 12:58 AM, Rick Altherr <raltherr at google.com> wrote:
>> The difference really is just with signal match rules and I don’t really see that one approach over the other
>> provides any more or less flexibility.  If you want signals for an entire class of sensors, you just use
>> the pathnamespace match rule.
> 
> As long as you feel we have this covered with a mapper call or a signal
> filter I am fine.  I was concerned with, especially, the number of calls
> the REST server would need to do in order to subscribe to all the
> sensors.
> 
>>> 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’?
>> 
>> Patrick - after reading this again I don’t understand.  Why would you not just use
>> the path namespace to resolve the type?
> 
> I think this was making leap that we would require / document paths as
> well.  Maybe that is the right thing to do but we don't have a currently
> defined mechanism for it.  I'm especially not happy with 'fan_tach' as a
> path match string.
> 
> -- 
> Patrick Williams
> _______________________________________________
> openbmc mailing list
> openbmc at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161110/8cb42944/attachment.html>