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

[Alexander Leidinger]

Quoting John-Mark Gurney <gurney_j at resnet.uoregon.edu> (from Tue, 16  
Oct 2007 10:57:26 -0700):

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

I think we maybe haven't talked about the same things... in  
Constantines sensors framework (the code which is responsible to fill  
hw.sensors with data) I still think there's no room for userland data.  
See my description of different sensor frameworks on arch from  
yesterday).

This is decoupled from e.g., lm.4. So far we have no safe way of  
querying such devices from userland. lm.4 gives us the safe way. It's  
tested in OpenBSD to not harm systems, and our sysctl interface (via  
Constantines sensors framework) allows to export the data in a safe  
way (compared with e.g., todays situation with mbmon with elevated  
privileges which give full access to the application which queries the  
hardware). It also serves as a good example of using Constantines  
sensors framework with known to work code. Constantines work contains  
a little bit of userland code, to give the user something to play  
with. The main part of the work was the in-kernel framework, not the  
userland part. For Constantines project in the soc, the userland work  
proposed in the thread on arch was out of scope.

lm.4 is used to access common hardware on mainboards. Currently you  
need elevated privileges without any protection layer between the code  
doing the data reading and the user requesting it. With lm.4 and the  
sensors framework we have our sysctl framework as a protection layer  
in between. I don't say everything needs to be in the kernel, but the  
current situation is not good, and this we get for free. If there's  
some kind of framework, where the lm.4 stuff can be added to the  
userland to get similar benefits we get with lm.4, I surely don't  
object to move it there (systems evolve, and I welcome this). But  
Constantines project was not about such a framework, and nobody is  
working on something like this. So it's not that I object in general,  
it's that we don't have the infrastructure to move in this direction.

> 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

Robert is talking about what fits into single-system sensors framework  
on 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

Poul was arguing that there's no benefit from Constantines sensors  
framework and  wanted to do something what I call a single-system  
sensors framework in the mail to arch from yesterday (he didn't care  
to look even at the architecture of Constantines work). Nobody is  
saying that a single-system sensor framework is not a good idea (if it  
belongs to ports or into our basesystem e.g., via using our bsnmp or  
by writting something else, is not something I care much about), but  
Poul said Constantines work (the idea behind, to export sensor data  
via a common API from the kernel, so that users of FreeBSD don't have  
to go and hunt down sensor data from the kernel from a lot of places  
and that developers don't have to reinvent the wheel how to export the  
data from the kernel) is not worth our time.

> 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

Doug suggested to do a combination of what I describe in my mail to  
arch from yesterday as a kernel sensors framework and a single-system  
sensors framework. Constantines work was about the part of a kernel  
sensors framework. He also provided some userland code so that data  
from the kernel sensor framework can be logged into syslog, and that  
users can see this data in a top-like fashion. Doug was not saying  
something against the kernel sensors framework. And I think he said  
what he said based upon what he has read in Pouls mails.

> 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

Somehow I get a mail from Robert when I follow this link. Regarding  
what you wrote as the explanation for the link: Poul objected to the  
entire kernel work Constantine was doing, without looking at the  
architecture or the code. I was explaining that Constantines work was  
about providing a way of exporting sensor data from the kernel to the  
userland and that nobody prevents us to run some sensor data collector  
program (what I better describe as a single-system sensor framework in  
my mail to arch from yesterday) in userland. Poul was focused on his  
userland approach without any common API to access kernel stuff  
(Constantines work). He also didn't continue the discussion

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

It's easier to write safe code to do the lm stuff (this stuff is less  
complex) in the kernel, than it is to write a safe infrastructure  
which "only" gives access to ISA I/O (you can do a lot with ISA I/O  
access, it needs to be in a way that resources there which are bound  
by drivers in the kernel don't get circumvented), as the complexity is  
different.

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

There are critical bugs, and non-critical bugs. If you give userland  
access to ISA resources on a "common use" instead of a "rare  
circumstances" base (which would be the case in an interval based  
monitoring) in our current infrastrucuture, I'm not convinced, that is  
is that much easier. If we talk about a hypotetical  
ISA-access-infrastructure, which prevents the use of malicious things  
with kernel-attached devices, then the situation looks different.

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

And Constantines sensors framework is supposed to give a common API to  
transport 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...

You are talking about what I call a group-level sensors framework. See  
my mail from yesterday to arch how this fits into my current view of  
the world with Constantines sensors framework.

Bye,
Alexander.

-- 
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137
Dr. Zoidberg: "Now I'm not saying Professor Farnsworth is old, but if you
consider his age he's likely to die soon."