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 ...
gurney_j at resnet.uoregon.edu
Wed Oct 17 17:00:37 PDT 2007
Andrey Chernov wrote this message on Thu, Oct 18, 2007 at 00:23 +0400:
> gOn Tue, Oct 16, 2007 at 06:40:47PM +0200, Alexander Leidinger wrote:
> >> like /var/run/log or /var/run/devd.pipe, that a userland daemon running
> >> as root that has access to ISA I/O and related resources... It's
> >> that simple...
> > And the code doesn't exists. And when it is written, when will it be
> > bugfree enough? The sysctl way of exporting integer data already has a good
> > track record, and porting the existing lm sensor (from a project which is
> > known to take much care about security) was easier to get right. The
> > project also was not about the lm sensor (I don't go and count the size for
> > the small lm sensor now). The lm sensor was one example of using it. I
> > don't think objection to the lm sensor driver should lead to removal of the
> > framework itself. One possible reaction could be to say that the lm sensor
> > should move to ports.
> Why not to put them under DEVFS like /dev/sensors/* ? They are devices
> after all. I agree that putting devices under sysctl.* is bad idea.
a) How does a userland driver present a DEVFS/device instance?
b) For exporting a simple integer, sysctl makes more sense than the
device interface. (I'm not getting into naming the sysctl node, or
where it should be located.)
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
More information about the cvs-src