On 16-Nov-99 eric.delcamp@legrand.fr wrote:
One at a time here...

> Why did you not join theses 2 structures by adding "units" to temperatures
> and rpms ? 

uhhh..  dunno.. might as well.

> This will simplify the API and a unit for temperature (Celsius. or
> Faren.) is not stupid (only loose u_int in case of rpm). MicroKelvins are a
> little weird for our application domain (but usefull for externals sensors).

The reason I chose kelvin was because that way the kernel provided a consistent
interface to userland.  If you KNOW you are getting kelvin, then you know
exactly what the conversion factor is for more human-friendly output.  If you
spit out varying things with a flag, then programs have to have code for all
three conversions in them.

> If theses values are hexadecimal flags, it should be something like : 0x02,
> 0x04, 0x08, 0x10.

Thats definately a typo in the API.. thanks for pointing it out.

> 
> This API seems OK for me, but it ignore one major interrest of having sensors
> in a computer : watchdog. Maybe we need an interface to set watchdog values
> and a reaction mechanism to theses values (API 1.1 ?).

Personally I feel that this stuff should be done in userland anyhow.  I'm not
saying there shouldn't be an API extension, or separate API if people want to
do that.. but I think it should be totally optional to the ENVSYS API.

---
Tim Rightnour <root@garbled.net>
NetBSD: Free multi-architecture OS http://www.netbsd.org/
NetBSD Mailing lists on the web: http://mail-index.netbsd.org/