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 Fri, Oct 19, 2007 at 13:35 +0200:
> 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).

As long as you still think there is no room for userland bits, I
doubt you'll ever get buy off on the group raising the issues...  I
admit I haven't done as much kernel work as others like phk and
Warner, but I have learned that the kernel should never be a dumping
ground, "just because it's easier"TM...

> 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  

And why can't the lm.4 be designed to export it's data to a userland
daemon instead of to the sensore framework?

> 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  

This is obviously where you don't get where phk and I talk about using
the kernel as a transport layer...  You write enough of the driver in
kernel to talk w/ the hardware in a non-destructive way, and let the
userland part do the rest of the work...

> 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  

You have an interesting definition of free...  No code is free...  Are
you going to guarante that you will promptly fix all bugs w/ the code?

> 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  

Umm... just above you just said that you don't believe in userland
data, so how do you reconcile this statement?  Here you are saying
you do support it, or am I missing a qualification to your statements?

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

And it's a good step to take, and I'm sure Constantine has learned a
lot about FreeBSD doing the project, and that's great.  But a SoC
project does not get an immediate green light w/o review from the
FreeBSD community...

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

Looks like that was the link to the message he replied to..  The correct
link is:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=170761+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  

Yet, the code can/will prevent a proper userland implementation from
being developed, and additional drivers that don't belong in the kernel
to be written because they don't have the single-system sensor framework..
The only way to easily get systat to display their sensor's data is
to use the kernel framework, and so suddenly we have more code in the
kernel than we should of if we had properly done the job in the first
place...

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

I'll admit I don't know how LM78 and friends are implemented, so I
can't say for sure what the design of a "transport" kernel driver would
look like for the sensors, or even if it would make sense...

But we aren't talking about a specific hardware implementation...  You
keep bringing up lm, but what about i2c sensors that are on small
embedded systems and the like?  My TS-7200 has a temp sensors on the
i2c bus..

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

Ok, I never _EVER_ suggested giving a userland program ISA IO access...
That's the point of the transport kernel layer driver to do the ISA IO
access on behalf of the requesting userland daemon...

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

But it also prevents userland sensors from being included in the
systat agreegation of sensors...

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

No, I am talking about your system-level sensor idea...  NUT was partly
a bad example since it's inter-machine, but anything that is inter-machine
can easily be scaled to intra-machine...

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

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