Re: W1: w1_slave units, standardize 1C or .001C? Break API

[David Fries <david@fries.net>]

On Wed, Jan 23, 2008 at 12:06:27AM +0300, Evgeniy Polyakov wrote:
> 
> What about instead of breaking application just add new sysfs file,
> which will only return temperature instead of full rom content.
> It can be millidegrees Centigrade, another one can be millikelvins :)

If someone wrote their application to read degrees C because they have
an ds18b20, the application will break anyway if they run it with an
ds1820 sensor.  Or the opposite way around.  Yes it would be better
not to break a program, but I think having a consistent interface for
both sensors to be a better option.

> Actually it is already posible for applications to decode whatever
> precision they like from the rom content displayed, although that can be
> not very convenient.

I was first surprised then glad that the raw data was included in the
user available data.  I was wanting the full precision, so that was my
plan.

> Even more, what about possibility of changing of the base, relative to
> which temperature is displayed? By default I vote for centigrades,
> those, who live behind the oceans, can setup Fahrenheit, Kelvin or anything
> else, but please in a new file :)
> David will this work for you?

I'm biased toward Fehrenheit, against Kelvin, but I think continuing
to keep Centigrade is the correct choice here.  I don't like the idea
of selecting the base the kernel displays by a userland option, too
easy to make assumptions, give it one interface and let the
application do the conversion, C/1000.0*9/5+32 is pretty easy (for
millidegrees C that is).

I'll get the trivial patch to change the ds18b20 output in
millidegrees C to make things consistent.  I'm out of time tonight.

It does sound like a good idea to have a sysfs file that just returns
the millidegrees C in ASCII without any other text.  It would be
easier to parse.  If the conversion fails return 0 bytes.  Just an
idea, but if someone wants it they can write the patch.

-- 
David Fries <david@fries.net>
http://fries.net/~david/ (PGP encryption key available)