dbus-sensors:hwmontemp: additional attribute proposal

[Ed Tanous]

On Fri, Aug 7, 2020 at 9:28 AM James Feist <james.feist at linux.intel.com> wrote:
>
> 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.
>

+1  If we're talking about adding this to PSU sensor.  For
dbus-sensors,  this feels like an already solved problem, even if the
particular sensor you're using might not have implemented the pattern
yet.

If we're talking about phosphor-hwmon, I think that's a very different
discussion, and one I don't have a strong opinion on.