Comments on Sensor design.

[Patrick Williams]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161106/6f48f5b8/attachment.sig>