cvs commit: src/etc Makefile sensorsd.conf src/etc/defaults rc.conf src/etc/rc.d Makefile sensorsd src/lib/libc/gen sysctl.3 src/sbin/sysctl sysctl.8 sysctl.c src/share/man/man5 rc.conf.5 src/share/man/man9 Makefile sensor_attach.9 src/sys/conf files ...

[Andrey Chernov]

On Thu, Oct 18, 2007 at 01:33:22AM -0700, John-Mark Gurney wrote:
> > (in general sensor can be more complicated than single integer) why 
> 
> If it's more complicated then that's different, but from my understanding
> of the OpenBSD sensor framework is that you'd end up breaking those
> "complicated" sensors into seperate sensors...

I don't like OpenBSD sensors framework like almost everybody here:) I 
don't think that breaking complicated sensors into separate pieces is good 
idea. Usually reading/writing DEVFS device + few ioctls for complex cases 
must cover most complicated sensors.

> > userland driver is ever needed? Simple daemon is enough.
> 
> Exactly my point...  A userland driver is necessary if all sensores are
> to be listed in /dev/sensors/*...  If it's only a subset that a userland
> library uses to query a few sensors like current cpu temperature, and
> the rest from a userland daemon, that's fine too...  But /dev/sensors/*
> is should not be the complete or primary source of sensor data...

I have nothing against userland drivers, but prefer to have sensors into 
easy to use namespace (and, as devices after all, under DEVFS) with 
ability to set permissions for them separately, like file system allows.

-- 
http://ache.pp.ru/