From: Jean Delvare <khali@linux-fr.org>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] Why internal sensor on atom cpu isn't yet
Date: Tue, 28 Apr 2009 14:36:01 +0000 [thread overview]
Message-ID: <20090428163601.3f70b7fe@hyperion.delvare> (raw)
In-Reply-To: <1240762029.10972.15.camel@maxim-laptop>
On Tue, 28 Apr 2009 06:31:16 -0700, Philip Pokorny wrote:
> Why doesn't this fit the current temperature interface? What is there in the interface that says it has to be an absolute temperature and not a relative temperature?
This isn't spelt out explicitly, but it is pretty implicit. Suddenly
reporting relative temperature margins the same way we report absolute
temperature values will only confuse the user (and ourselves.) When
sensors report "+20 degrees", how will you know whether the system is
totally overheating or if it is rather cold?
If we start reporting temperature margins, the interface must be
different from what we have today so that libsensors and other tools
relying on our sysfs interface aren't screwed up. We want sensors and
other tools to clearly label temperature margins as such.
And really I think it makes a lot of sense to report relative
temperatures, I have no objection to doing that. The absolute
temperature is one thing, but the key information is whether the system
is running within its thermal specs or not.
> Alarms, min-max, hysterisis, etc all still work the same, they are just shifted so that the max limit is zero and the typical values are less than zero. We allow negative temperatures in the library.
Just because we support them in the library doesn't mean all
applications support them. I fixed a bug with negative temperatures in
sensord a few months ago... Anyway the problem is not with negative
values. The problem is that users must _know_ what they are seeing.
So please let's not rush here. The proper interface, both at the sysfs
and libsensors levels, should be discussed.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
prev parent reply other threads:[~2009-04-28 14:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-26 16:07 [lm-sensors] Why internal sensor on atom cpu isn't yet supported? Maxim Levitsky
2009-04-28 10:39 ` [lm-sensors] Why internal sensor on atom cpu isn't yet Rudolf Marek
2009-04-28 13:13 ` Jean Delvare
2009-04-28 13:18 ` Maxim Levitsky
2009-04-28 13:25 ` Jean Delvare
2009-04-28 13:27 ` Philip Pokorny
2009-04-28 13:31 ` Philip Pokorny
2009-04-28 13:31 ` Maxim Levitsky
2009-04-28 14:36 ` Jean Delvare [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090428163601.3f70b7fe@hyperion.delvare \
--to=khali@linux-fr.org \
--cc=lm-sensors@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.