Porting OpenBSD's sysctl hw.sensors framework to FreeBSD

[Robert Watson]

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