> I think it would be good to have some kind of standard way to access
> this kind of devices. This should also include watchdogs.
well, theres just the problem of those different infos the devices can
provide you. acops only says OK/BAD, while lm75/78 give you some numbers.
(btw: don't trust the values given by the lm78, the chip is about 5-8 mm
away from the surface of the cpu, you have to add an cpu-specific offset
of 3-10 or so degrees celsius to get the correct values. somewhere inside
the bios there's such a table (at least on the asus tx-97))
but anyhow, have a look at intels SMBus specifications (if they are still
available). it's an I²C bus for system management, on the asus tx97 there
are the lm75, the lm78 and all SDRAM-slots connected to it. so it would
be more logical to have an SMBus-procdevice (/proc/bus/SMBus ??) with
submodules like lm75, lm78 or whatever you connect to it. (remember, I²C
is an widely used industry standard.) but this way, there's the problem,
that acops isn't realized via the SMBus/I²C of the TX (i think bx has it,
too) but thru using some generic I/O pins of the chipset.
> If they use the same input/ouput via proc it is much easier to use this
> information with mon and/or linux-ha.
yes. how about a procdevice like /proc/sys/hardware (== file)
containing a clear but open syntax, like "name value unit state".
where value is !surprise! the value (numerical or ok/bad) and state is
something like ok/bad. we need the state field, because "1236" can be
good or bad and the reading program perhaps don't know what
"merced-internal-temperature" means ;)
> Something which simple to parse like:
>
> /proc/monitor/lm78:
> Sensor-1-Temp 50 C
> Sensor-1-Fan 4000 RPM
> core 2.8 V
> cpu 3.5 V
yes, but how does joe user know if 4000 rpm means good or bad?
> Christof Damian
> Technical Director
> http://www.mediaconsult.com/ ( btw: mediaconsult is hiring )
CU
Karsten aka TI
Visit my Homepage: http://www.tu-chemnitz.de/~kapet
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu