<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div style="font-family: monospace; font-size: 11px;" class="">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):</div><div style="font-family: monospace; font-size: 11px;" class=""><br class=""></div><div style="font-family: monospace; font-size: 11px;" class="">/xyz/openbmc_project/sensors/temperature</div><div style="font-family: monospace; font-size: 11px;" class=""><br class=""></div><div style="font-family: monospace; font-size: 11px;" class="">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.</div><div style="font-family: monospace; font-size: 11px;" class=""><br class=""></div><div style="font-family: monospace; font-size: 11px;" class="">So I am proposing just a handful of interfaces for now, found here:</div><div style="font-family: monospace; font-size: 11px;" class=""><br class=""></div><div style="font-family: monospace; font-size: 11px;" class=""><a href="https://gerrit.openbmc-project.xyz/#/c/1106" class="">https://gerrit.openbmc-project.xyz/#/c/1106</a></div><div style="font-family: monospace; font-size: 11px;" class=""><br class=""></div><div style="font-family: monospace; font-size: 11px;" class="">This should give us enough definition and still be flexible.</div><div style="font-family: monospace; font-size: 11px;" class=""><br class=""></div><div style="font-family: monospace; font-size: 11px;" class="">Moving past the API definition…there is an unfinished hwmon monitoring application out there:</div><div style="font-family: monospace; font-size: 11px;" class=""><a href="https://github.com/openbmc/phosphor-hwmon" class="">https://github.com/openbmc/phosphor-hwmon</a></div><div style="font-family: monospace; font-size: 11px;" class=""><br class=""></div><div style="font-family: monospace; font-size: 11px;" class="">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.</div><div style="font-family: monospace; font-size: 11px;" class=""><br class=""></div><div style="font-family: monospace; font-size: 11px;" class="">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.</div><div style="font-family: monospace; font-size: 11px;" class=""><br class=""></div><div style="font-family: monospace; font-size: 11px;" class="">I’m sure I’ve probably missed something - please let me know.</div><div style="font-family: monospace; font-size: 11px;" class=""><br class=""></div><div style="font-family: monospace; font-size: 11px;" class="">thx - brad</div></div><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 6, 2016, at 10:54 PM, Patrick Williams <<a href="mailto:patrick@stwcx.xyz" class="">patrick@stwcx.xyz</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Wed, Nov 02, 2016 at 10:12:47AM -0400, Brad Bishop wrote:<br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">On Nov 2, 2016, at 12:58 AM, Rick Altherr <<a href="mailto:raltherr@google.com" class="">raltherr@google.com</a>> wrote:<br class=""></blockquote>The difference really is just with signal match rules and I don’t really see that one approach over the other<br class="">provides any more or less flexibility. If you want signals for an entire class of sensors, you just use<br class="">the pathnamespace match rule.<br class=""></blockquote><br class="">As long as you feel we have this covered with a mapper call or a signal<br class="">filter I am fine. I was concerned with, especially, the number of calls<br class="">the REST server would need to do in order to subscribe to all the<br class="">sensors.<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">In both cases the dbus path could contain the 'type':<br class=""> /xyz/openbmc_project/sensors/temperature/ambient<br class=""> /xyz/openbmc_project/sensors/fan_tach/fan0<br class=""><br class="">The question is essentially should the "Unit" property be used to<br class="">resolve the 'type' or should we have distinct interfaces for each<br class="">'type’?<br class=""></blockquote><br class="">Patrick - after reading this again I don’t understand. Why would you not just use<br class="">the path namespace to resolve the type?<br class=""></blockquote><br class="">I think this was making leap that we would require / document paths as<br class="">well. Maybe that is the right thing to do but we don't have a currently<br class="">defined mechanism for it. I'm especially not happy with 'fan_tach' as a<br class="">path match string.<br class=""><br class="">-- <br class="">Patrick Williams<br class="">_______________________________________________<br class="">openbmc mailing list<br class=""><a href="mailto:openbmc@lists.ozlabs.org" class="">openbmc@lists.ozlabs.org</a><br class="">https://lists.ozlabs.org/listinfo/openbmc<br class=""></div></div></blockquote></div><br class=""></body></html>