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 gurney_j at
Thu Oct 18 01:33:25 PDT 2007

Andrey Chernov wrote this message on Thu, Oct 18, 2007 at 05:14 +0400:
> On Wed, Oct 17, 2007 at 05:00:33PM -0700, John-Mark Gurney wrote:
> > > 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.)
> Your a) and b) are in logical conflict. If they are only simple integers 

I never said they weren't...  You asked why don't we put simple sensors
like fan rpm as a device such as /dev/sensors/fan0, I replied w/ two

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

> 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 think loadable kernel modules are not worse than userland drivers since 
> can be used only by those who needs them. 

Besides violating the first rule of kernel programming...

  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 mailing list