dbus-sensors:hwmontemp: additional attribute proposal

Jason Ling jasonling at google.com
Sat Aug 8 02:34:34 AEST 2020

sounds like I'm better off just moving temp sensors over to being handled
by PSUSensors.

Slightly different topic:
What about making the device/type lists in PSUSensors extendable using JSON?

On Fri, Aug 7, 2020 at 9:24 AM James Feist <james.feist at linux.intel.com>

> On 8/6/2020 3:52 PM, Jason Ling wrote:
> > Assuming that you mean "Omit Name attribute from the sensor
> > configuration definition and then change hwmontemp to require any Name.*"
> > This won't work since Entity-Manager requires Name (tried it,
> > entity-manager does indeed complain about not finding name).
> >
> > My rationale for an omit list vs permit list
> > (1) if it's a permit list then everytime you add another temp you want
> > to monitor you need to add to this list..if you want to drop a temp then
> > you have to modify the list again.
> > (2) General assumption is that the primary use case is to display all
> > named temperatures which means a permit list is typically large
> > (3) adding a permit list also breaks all existing code. Everyone has to
> > go back into their json config and add all the sensor values to the list.
> >
> > My rationale for using the value for the "Name" attribute rather than
> > labels or referencing sysfs attributes
> > (1) Looking at just the config , it's obvious as to what you're omitting.
> > (2) If it's label base, a label change in a driver would mean a breakage
> > in the userspace daemon. Not a big deal; but it can be annoying.
> > (3) if it's sysfs attribute based then it's my opinion that it's not as
> > readable.
> >
> I'm not a huge fan of this as the PSU sensor already has a way of
> handling this, and it adds a new way of handling it. I'd rather follow
> what is already there. It's already confusing enough that hwmontemp and
> psu do things in slightly different ways.
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200807/3fca78f3/attachment.htm>

More information about the openbmc mailing list