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 ...
ache at nagual.pp.ru
Thu Oct 18 02:10:17 PDT 2007
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.
More information about the cvs-src