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 ...

[John-Mark Gurney]

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."