On Wed, Jan 02, 2019 at 08:05:03PM -0500, Greg Troxel wrote: > Artturi Alm <artturi....@gmail.com> writes: > > > On Tue, Jan 01, 2019 at 12:03:31PM -0500, Greg Troxel wrote: > >> So, I wonder why you are choosing kPa vs hPa, and if that choice ends > >> up being a framework choice for everything. And how the rest of the > >> world deals with this issue. > > > > By accident, i guess, and after having read about pascals on wiki[0], > > it felt like a good choice, for being "not just for meteorologists", > > nor imperial, but i'm from metric .eu, fwiw.. > > Interesting article, and it seems right. > > Atmospheric pressure is basically meteorology, IMHO. >
Alone as is, sure, but here i have it on a sensor with temperature and humidity too, and the datasheet does list only one meteorology related typical application for it, the weather forecast, among the not as obvious "flying toys"/"indoor navigation" etc.. > > I actually got *= 1000 for mPa in the driver, so i don't really care > > about the unit to be used, as long as it's not loosing any precision/ > > limiting range (for kernel -> user, so Pa would work just as well, and > > i'm not sure whether mPa does buy anything w/r.t. future sensors, it > > was more about minimal diff looking reasonable). > > The comments about integers, range and precision are compelling. It's > hard to imagine anything in envsys delivering more than 1 Pa of > precision. > > I didn't mean to give you a really hard time about this. It just felt > like a decision that was likely to control how all envsys pressure > reporting is done in NetBSD, for all time. But maybe I'm misperceiving > that. > Much appreciated, somehow i wasn't thinking of this as a part of any API, while i know it kind of is, so better indeed to get it right :] -Artturi
