linux-kernel - Re: [PATCH v3] k10temp: temperature sensor for AMD Family 10h/11h CPUs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091124142654.76f4d166@hyperion.delvare>
Date:	Tue, 24 Nov 2009 14:26:54 +0100
From:	Jean Delvare <khali@...ux-fr.org>
To:	Clemens Ladisch <clemens@...isch.de>
Cc:	Serge Belyshev <belyshev@...ni.sinp.msu.ru>,
	linux-kernel@...r.kernel.org, lm-sensors@...sensors.org
Subject: Re: [PATCH v3] k10temp: temperature sensor for AMD Family 10h/11h 
 CPUs

On Tue, 24 Nov 2009 09:43:29 +0100, Clemens Ladisch wrote:
> Jean Delvare wrote:
> > On Mon, 23 Nov 2009 16:29:25 +0100, Clemens Ladisch wrote:
> > > There still is the built-in diode to be read by the motherboard, but the
> > > internal sensor was never intended to be an absolute measurement but
> > > just as a means for controlling the cooling.
> > 
> > Still we use it for that purpose at the moment. Maybe we simply should
> > not?
> 
> Well, the absolute measurements have essentially the same purpose, and
> would not make much sense without comparing them to some absolute limit.

Of course. The problem is that users don't know that the temperature
isn't real, and then get puzzled when comparing with other temperature
sensors in their system, which _do_ report physical temperatures.

> In any case, it might make more sense to show such values as something
> like "20 °C below maximum".

I think so, yes. Now the difficulty is to come up with a suitable sysfs
interface. Dropping the current interface altogether doesn't sound
right as it will take time before a new version of libsensors is
written and spread out and all applications add support for the new
interface. In the meantime, I guess we want users to still see the
approximate value.

So ideally we would come up with an interface that adds up to the one
we have currently. Future libsensors/applications could read the extra
information to display the value in a different format so that the
users see the difference.

An idea I have about this is adding a sysfs file temp#_relative, which
would contain the fake temperature value that is used as a reference
for the thermal sensor in question. In the case of k10temp, the value
would be 70000. So for example we would have:

temp1_input: 46000
temp1_relative: 70000

Old applications would display this as 46°C while new ones would
display "24°C below the limit". For coretemp this could be 85000 or
100000 (at least in the case where we don't know the limit for sure.)

If there are limits exported (temp1_max, temp1_crit etc.) the same
offset could be applied to them too.

This approach has the advantage of backwards compatibility. It may not
be considered flexible enough though... For example it does not support
sensors with totally arbitrary scales (where 1000 != 1°C.) I seem to
remember we've seen this in the past?

If others have ideas about how we can support this, I'm all ears.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/