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
| ||
|
Date: Tue, 22 Jan 2008 22:00:51 -0600 From: David Fries <david@...es.net> To: Evgeniy Polyakov <johnpol@....mipt.ru> Cc: linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com> Subject: Re: W1: w1_slave units, standardize 1C or .001C? Break API 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@...es.net> http://fries.net/~david/ (PGP encryption key available) -- 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/
Powered by blists - more mailing lists