Date: Wed, 11 Jul 2007 12:15:13 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Rui Paulo <rpaulo@fnop.net>, Shteryana Shopova <syrinx@FreeBSD.org>, freebsd-arch@FreeBSD.org, "Constantine A. Murenin" <cnst@FreeBSD.org> Subject: Re: Porting OpenBSD's sysctl hw.sensors framework to FreeBSD Message-ID: <20070711115332.I67691@fledge.watson.org> In-Reply-To: <56113.1184151154@critter.freebsd.dk> References: <56113.1184151154@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 11 Jul 2007, Poul-Henning Kamp wrote: >> This doesn't argue for doing nothing, just that perhaps a kernel device >> driver is the wrong place. > > 100% agreement here. > > I would prefer to see the kernel drivers only offer transport and have all > the MIB stuff happen in userland. > > In other words, I think the right way to think about this is: "Assume the > existence of sensord(8), design client (sensors) and server (apps that want > to know what the sensors show) APIs" > > Another thing to remember is that not all sensors relating to a system lives > inside the system. Voltage, Fire, Temperature and other relevant sensors > may need network or serial port communication instead if i2c or IPMI, but > that doesn't mean that it shouldn't be possible to integrate it in the > sensor MIB. OK, so perhaps some more back-to-basics consideration is required. The presumed goal of a "kernel sensors framework" is to do things like provide common accessor methods, event management, and a registration mechanism for things that are "sensor-like". I don't think we need to introspect too much on the meaning of "sensor-like". We already have the sysctl framework available as a way to export lightly typed data from the kernel via a MIB. The usual way that we "group" related entries is to have them in a common part of the name space -- i.e., security, hw, or perhaps hw.sensors. This falls down a bit when you want to group things by more than one paramater -- i.e., bus location or node type, as we have support for very few node types, so there's a tension between putting information about devices in, say, dev.fdc.* and hw.sensor.fdc.*, where putting it in the former groups it by the device driver / device instance, and via the latter groups it as "sensor-like". I think this is where the registration bit comes in -- just as being able to iterate through general sysctl nodes is useful, being able to identify nodes of particular interest for monitoring (i.e., sensor-like) is quite useful for allowing the automated generation of log data, etc. A question I've not yet seen answered about the OpenBSD sensor framework is whether it addresses the issue of asynchronous notification -- one that we've still been coming to grips with for things like hardware device arrival via devd. The obvious comparison comes up here with SNMP, which offers a MIB, registration (by definition things in SNMP are of interest to monitoring), and event management (trap notification). Should we simply be turning on bsnmpd by default for the loopback interface and fleshing out the local monitoring tool suite to be able to use SNMP? Something I've wanted for a long time is the ability to use most of our existing management tools on remote boxes via SNMP -- i.e., "vmstat -z -H remote.host". Does sensord provide specific infrastructure beyond what already exists in our SNMP daemon or via the SNMP protocol -- is it reasonable to merge that functionality into an SNMP daemon? So it sounds like it would be useful for Constantine to help flesh out a few pieces of understanding: - How does having the kernel sensor framework compare with simply using sysctl as it stands today? - Does the sensor framework provide a trap mechanism, something that has historically been missing from our sysctl framework? - Does the stronger typing associated with sensor framework nodes, by virtue of imposed structure, significantly help in writing management tools? - The same functional comparisons with SNMP/bsnmpd/snmp tools and libraries. I think one of the observations made earlier in this thread -- that sensor events can come from the kernel, user space, or even distributed systems, is key to understanding what we may need out of a general sensor abstraction. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070711115332.I67691>