Date: Fri, 19 Oct 2007 13:35:00 +0200 From: Alexander Leidinger <netchild@FreeBSD.org> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: Wilko Bulte <wb@freebie.xs4all.nl>, Poul-Henning Kamp <phk@phk.freebsd.dk>, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: 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 ... Message-ID: <20071019133500.epngxkctq88c8s00@webmail.leidinger.net> In-Reply-To: <20071016175726.GS39759@funkthat.com> References: <20071015152408.10kvgtog6cooc4wc@webmail.leidinger.net> <48258.1192460507@critter.freebsd.dk> <20071015210909.1b6b693b@deskjail> <20071015202115.GP39759@funkthat.com> <20071016184047.8zh3fl90gksks40c@webmail.leidinger.net> <20071016175726.GS39759@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting John-Mark Gurney <gurney_j@resnet.uoregon.edu> (from Tue, 16 =20 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@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 +02= 00: >> >>> >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 =20 Constantines sensors framework (the code which is responsible to fill =20 hw.sensors with data) I still think there's no room for userland data. =20 See my description of different sensor frameworks on arch from =20 yesterday). This is decoupled from e.g., lm.4. So far we have no safe way of =20 querying such devices from userland. lm.4 gives us the safe way. It's =20 tested in OpenBSD to not harm systems, and our sysctl interface (via =20 Constantines sensors framework) allows to export the data in a safe =20 way (compared with e.g., todays situation with mbmon with elevated =20 privileges which give full access to the application which queries the =20 hardware). It also serves as a good example of using Constantines =20 sensors framework with known to work code. Constantines work contains =20 a little bit of userland code, to give the user something to play =20 with. The main part of the work was the in-kernel framework, not the =20 userland part. For Constantines project in the soc, the userland work =20 proposed in the thread on arch was out of scope. lm.4 is used to access common hardware on mainboards. Currently you =20 need elevated privileges without any protection layer between the code =20 doing the data reading and the user requesting it. With lm.4 and the =20 sensors framework we have our sysctl framework as a protection layer =20 in between. I don't say everything needs to be in the kernel, but the =20 current situation is not good, and this we get for free. If there's =20 some kind of framework, where the lm.4 stuff can be added to the =20 userland to get similar benefits we get with lm.4, I surely don't =20 object to move it there (systems evolve, and I welcome this). But =20 Constantines project was not about such a framework, and nobody is =20 working on something like this. So it's not that I object in general, =20 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=3D174429+0+/usr/local/www/db/= text/2007/freebsd-arch/20070715.freebsd-arch Robert is talking about what fits into single-system sensors framework =20 on arch. > phk talking about userland for MIB and kernel for transport: > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D170761+0+/usr/local/www/db/= text/2007/freebsd-arch/20070715.freebsd-arch Poul was arguing that there's no benefit from Constantines sensors =20 framework and wanted to do something what I call a single-system =20 sensors framework in the mail to arch from yesterday (he didn't care =20 to look even at the architecture of Constantines work). Nobody is =20 saying that a single-system sensor framework is not a good idea (if it =20 belongs to ports or into our basesystem e.g., via using our bsnmp or =20 by writting something else, is not something I care much about), but =20 Poul said Constantines work (the idea behind, to export sensor data =20 via a common API from the kernel, so that users of FreeBSD don't have =20 to go and hunt down sensor data from the kernel from a lot of places =20 and that developers don't have to reinvent the wheel how to export the =20 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=3D53014+0+/usr/local/www/db/t= ext/2007/freebsd-arch/20070715.freebsd-arch Doug suggested to do a combination of what I describe in my mail to =20 arch from yesterday as a kernel sensors framework and a single-system =20 sensors framework. Constantines work was about the part of a kernel =20 sensors framework. He also provided some userland code so that data =20 from the kernel sensor framework can be logged into syslog, and that =20 users can see this data in a top-like fashion. Doug was not saying =20 something against the kernel sensors framework. And I think he said =20 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=3D166332+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 =20 what you wrote as the explanation for the link: Poul objected to the =20 entire kernel work Constantine was doing, without looking at the =20 architecture or the code. I was explaining that Constantines work was =20 about providing a way of exporting sensor data from the kernel to the =20 userland and that nobody prevents us to run some sensor data collector =20 program (what I better describe as a single-system sensor framework in =20 my mail to arch from yesterday) in userland. Poul was focused on his =20 userland approach without any common API to access kernel stuff =20 (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 =20 complex) in the kernel, than it is to write a safe infrastructure =20 which "only" gives access to ISA I/O (you can do a lot with ISA I/O =20 access, it needs to be in a way that resources there which are bound =20 by drivers in the kernel don't get circumvented), as the complexity is =20 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 =20 access to ISA resources on a "common use" instead of a "rare =20 circumstances" base (which would be the case in an interval based =20 monitoring) in our current infrastrucuture, I'm not convinced, that is =20 is that much easier. If we talk about a hypotetical =20 ISA-access-infrastructure, which prevents the use of malicious things =20 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 =20 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 =20 my mail from yesterday to arch how this fits into my current view of =20 the world with Constantines sensors framework. Bye, Alexander. --=20 http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 Dr. Zoidberg: "Now I'm not saying Professor Farnsworth is old, but if you consider his age he's likely to die soon."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071019133500.epngxkctq88c8s00>