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]

Alexander Leidinger wrote this message on Tue, Oct 16, 2007 at 18:40 +0200:
> Quoting John-Mark Gurney <gurney_j at resnet.uoregon.edu> (from Mon, 15  
> Oct 2007 13:21:15 -0700):
> 
> >Alexander Leidinger wrote this message on Mon, Oct 15, 2007 at 21:09 +0200:
> >>> >I already told you last time
> >>> >that the current way (access to the i2c or smbus) needs more access
> >>> >rights than using the userland parts of the sensors framework.
> >>>
> >>> More rights than what exactly ?
> >>
> >>One popular userland temperature/voltage reading tool (as it supports a
> >>lot of popular devices) is mbmon. It is currently a SUID root
> >>application. It is like this as it accesses the smbus and/or ISA I/O
> >>ports directly. If we forget the ISA I/O ports part, we could maybe
> >>switch to a mbmon-user, but I don't really want to have such an user be
> >>able to query every device on the smbus.
> >>
> >>systat and sysctl are not SUID/SGID and don't require some special
> >>rights in /dev. I would say this is a big difference in favour of the
> >>sensors framework.
> >
> >Did you completely ignore the discussion back in July?  I didn't bring
> >it up, because someone else did, but the simple solution is a socket
> 
> Have you a pointer to it? I would like to analyze why I don't remember  
> to have seen this.

Hmm.. Looks like no one specificly stated a socket, plenty people
talked about userland, and a couple mentions of daemons..  You were so
against doing any userland work that the discussion never got far
enough to talk about design decisions and implementation...

Rober Watson talking about using the SNMP daemon:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=174429+0+/usr/local/www/db/text/2007/freebsd-arch/20070715.freebsd-arch

phk talking about userland for MIB and kernel for transport:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=170761+0+/usr/local/www/db/text/2007/freebsd-arch/20070715.freebsd-arch

Doug Ambrisko talking about doing it both as a userland and a kernel
interface:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=53014+0+/usr/local/www/db/text/2007/freebsd-arch/20070715.freebsd-arch

phk talking about why kernel is complicated and userland is better:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=166332+0+/usr/local/www/db/text/2007/freebsd-arch/20070715.freebsd-arch

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

And code in the kernel is guaranteed to be bug free enough?  I'd much
rather have "bug free" code in the userland where the stability of the
system isn't as greatly effected by the code than "bug free" code in
the kernel...

Also, I find writing bug free code much easier when done in userland
as it's easier to go through the debug/recompile/test steps than the
same for kernel code...

You also forget that code doesn't get frozen in time...  People will
work on it in the future, and it will change...  Can you guarantee
that it will be bug free enough for the lifetime of the code?

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

I've never talked about a specific sensor or anything...... I purely
argued for the agregation of data to happen in userland and the kernel
simply be a transport for the data to userland....

Maybe you should look at NUT: http://www.networkupstools.org/

It does a bit more than simply look at sensor readings, but it does
do things like report voltage, temperature, and current battery charge...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."