Hi,
I've been looking at some of the sensors using the envsys framework, and
adding the ability to get and set the hardware (sensor chip) limits. Two
aspects of envsys, related to initial values, seem strange to me:
1) we call setlimits immediately after getlimits
2) we call getlimits before reading sensor values
1) is entertaining because if we read a spurious value, the driver could
then program it back to the hardware. (I have had this happen - a reading
of 0xff (-1'C) was written back and the machine powered off instantly!).
The workaround was to ignore 0xff in this driver, but it doesn't handle the
general case of spurious readings, and if the hardware does a power off,
you can't tell what happens without debugging in the driver [#]. It also
seems pointless to me, because even if everything is read correctly, we
needlessly write those same values back to the hardware.
2) is awkward for chips that might not have sensors attached. For example,
if the fan reading is 0 at boot, we can assume that no fan is attached and
not set limits for that sensor. However, because envsys sets the limits
first, we have to read the values in the driver before setting the limits
to detect this. Altering the envsys framework to read the sensors before
the limits seems more sensible to me.
Is there a reason that envsys works like this? Does anyone know of any
adverse impact if I:
1) don't call setlimits at boot time, andonly call it if requested
(e.g by processing either sysctl.conf or envsys.conf)
2) read the sensor values at boot before calling getlimits
? Alternatively, is there a better way that I've missed?
Regards,
J
[#] This means that your machine will just shut down part way through boot.
As soon as interrupts are enabled and envsys runs, the limits that were
read in getlimits will be written back to the chip in setlimits.