Re: [PATCH v2] Add support for new attributes to libsensors and to the sensors command

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 8 Jan 2012 16:14:27 -0800, Guenter Roeck wrote:
> Hi Jean,
> 
> On Sun, Jan 08, 2012 at 04:45:02PM -0500, Jean Delvare wrote:
> > Hi Guenter,
> > 
> [ ... ]
> > >  
> > >  static const struct sensor_subfeature_list power_inst_sensors[] = {
> > > +	{ SENSORS_SUBFEATURE_POWER_AVERAGE, NULL, 0, "avg" },
> > 
> > I'm confused. This one was missing on purpose. For power sensors we
> > consider instantaneous and averaging sensors as different types. The
> > code in function print_chip_power is pretty clear about this. So, just
> > as all _INPUT subfeatures aren't listed in limit arrays,
> > SENSORS_SUBFEATURE_POWER_AVERAGE must not be listed.
> > 
> I looked this up again.
> 
> The idea was to support display of both instantaneous power and average power
> if both is provided by the chip/driver.
> 
> With the above, this is displayed as follows: 
> 
> power: 55mW (avg: 50mW, highest: 70mW)
> 
> In other words, average power is displayed as limit, similar to lowest/highest values,
> if instantaneous power is supported as well. If not, it is still displayed as before.
> 
> power: 50mW (highest: 70mW)
> 
> Do you have a better idea how to handle this case ?

Oh, this is pretty nice. Now this all makes sense, thanks for the
clarification.

However it looks like a specific hack for a specific problem, rather
than a generic solution. We have two sets of highest/lowest power
attributes, one for instant measurements and one for averaged
measurements. While your change makes it possible to display both the
instant and averaged value, it can only display one set of
highest/lowest limit. I supposed that a monitoring device could expose
both, even if yours does not.

So with this change you can't claim that you display all power
attributes. Rather, you special-cased SENSORS_SUBFEATURE_POWER_AVERAGE
to be either an input value or a limit value. This is certainly
acceptable as long as it is properly documented. But this makes me
wonder if it wouldn't be better to assume that all attributes may be
present, and input may be missing in which case we use average as the
measurement.

Well that was a long speech for a short conclusion: as far as I can
see, all we have to do is duplicate power_avg_sensors[] at the end of
power_inst_sensors[] and adjust the labels to avoid ambiguous
duplicates. As far as I can see you don't even need to touch the code
itself, except for stripping out the comment which claims that power
sensor flavors are assumed to be mutually exclusive.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors


[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux