public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Clemens Ladisch <clemens@ladisch.de>
To: Jean Delvare <khali@linux-fr.org>
Cc: linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org
Subject: Re: [PATCH v3] k10temp: temperature sensor for AMD Family 10h/11h CPUs
Date: Fri, 15 Jan 2010 10:57:58 +0100	[thread overview]
Message-ID: <4B503C26.7040902@ladisch.de> (raw)
In-Reply-To: <20100110154549.1e5d0098@hyperion.delvare>

Jean Delvare wrote:
> On Fri, 27 Nov 2009 14:03:29 +0100, Clemens Ladisch wrote:
> > +temp[1-*]_scale	Temperature scale type.
> > +		0: millidegrees Celsius (default if no _scale entry)
> > +		1: relative millidegrees Celsius; see below
> > +		2: millivolts; see below
> > +		other values: unknown
> 
> Maybe, yes. I am a little worried that older versions of libsensors
> will ignore this attribute. The good thing about this is that users
> will still get some value until they upgrade. The bad thing is that
> they will not know that the value isn't absolute. They are likely to
> get frightened by unexpected values and/or to complain to us about them.
> 
> I am wondering if a totally separate channel type wouldn't be
> preferable. The pros and cons would be inverted of course: older
> versions of libsensors would have zero support for that, and all
> applications would have to be updated to support it, but at least the
> meaning of the value would be totally clear. This would come at the
> price of some code duplication both in libsensors and applications
> though.
> 
> I guess it basically depends whether we want to consider a thermal
> margin as a "temperature measurement except that it's relative" or as
> something completely separate.

It's different from the millidegree/millivolt issue; millivolts can be
transparently converted by libsensors, while relative values must be
handled/displayed differently by the application.  So I think at least
in the libsensors API, relative values should be different.

(In any case, we should add temp#_scale at least for millivolts.)

> Honestly, I've been thinking about this
> for some time now and I simply don't know what we'd rather do :(

The sysfs interface is a somewhat internal interface; I think the main
question is whether old userspace (old libsensors or old apps using a
new libsensors) should be able to see relative values without knowing
that they are relative.

Coretemp and k10temp already exist and show relative values.  If we
introduced a new channel for relative values now, we would still have
problems with those drivers, so it might already be too late to avoid
problems for old userspace.


Best regards,
Clemens

  reply	other threads:[~2010-01-15 10:06 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4AF91F70.10106@ladisch.de>
2009-11-20  8:15 ` [PATCH] k10temp: temperature sensor for AMD Family 10h/11h CPUs Clemens Ladisch
2009-11-20 10:22   ` Serge Belyshev
2009-11-20 10:44     ` [lm-sensors] " Jean Delvare
2009-11-20 10:47     ` [PATCH v2] " Clemens Ladisch
2009-11-20 11:30       ` [lm-sensors] " Jean Delvare
2009-11-20 11:56         ` Clemens Ladisch
2009-11-20 12:18           ` Jean Delvare
2009-11-23  7:45             ` [PATCH v3] " Clemens Ladisch
2009-11-23 13:51               ` Jean Delvare
2009-11-23 15:29                 ` Clemens Ladisch
2009-11-23 19:05                   ` Jean Delvare
2009-11-24  8:43                     ` Clemens Ladisch
2009-11-24 13:26                       ` Jean Delvare
2009-11-24 14:09                         ` Clemens Ladisch
2009-11-24 20:11                           ` Jean Delvare
2009-11-25  9:51                             ` Clemens Ladisch
2009-11-26 20:44                               ` Jean Delvare
2009-11-27 13:03                                 ` Clemens Ladisch
2010-01-10 14:45                                   ` Jean Delvare
2010-01-15  9:57                                     ` Clemens Ladisch [this message]
2010-01-15 13:31                                       ` Jean Delvare
2009-11-24  8:43                     ` [PATCH v4] " Clemens Ladisch
2009-11-25 19:45                       ` Andrew Morton
2009-11-26  7:46                         ` Clemens Ladisch
2009-11-27 15:43                       ` Jean Delvare
2009-11-28  7:48                         ` Andrew Morton

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=4B503C26.7040902@ladisch.de \
    --to=clemens@ladisch.de \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox