Quoting John-Mark Gurney <[EMAIL PROTECTED]> (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 <[EMAIL PROTECTED]> (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."
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
