update_lock

Mark M. Hoffman mhoffman at lightlink.com
Wed Mar 31 03:30:48 CEST 2004


* Jean Delvare <khali at linux-fr.org> [2004-03-30 11:22:39 +0200]:

(snipped a lot of other stuff, so I can comment here first...)

> BTW I reiterate my agreement with Phil Pokorny's registers split between
> input values and limits. Having two different caching periods for these
> groups makes much much sense and is likely to speed chip updates up. I
> also agree that not updating limits at all wouldn't be clever, since
> sometimes motherboards write to them in our backs and it's something we
> have to be informed of.

In my opinion, the "cached update" scheme serves only one purpose, and
it's not speed.  Internally, some of these sensor chips actually pause
the sampling and conversion in order to answer an i2c/smbus request. If
we didn't have this scheme in place and some user did this:

	while [ true ]; do
		cat /sys/bus/i2c/devices/xyz/temp1_in > /dev/null
	done

.. the value would in fact never change.  But worse, it could also halt
the alarms, QFAN, smartfan, or whatever - i.e. a DOS attack against the
hardware.  Keep in mind that the proc/sysfs files are world readable.

All that said, I think that any further optimization of the update routine
for speed is just added complexity for little or no gain.  The data being
reported by these drivers are not real-time critical w.r.t. their present
application as PC hardware monitors. And in my experience, the precision of
PC hardware sensors is questionable at best anyway.

Bottom line: I don't think these drivers should be any more complex than
necessary.  Furthermore, I think that any tradeoff of simplicity for update
speed is bad for this class of drivers.  K.I.S.S.

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com



More information about the lm-sensors mailing list