sensors fun..

[Constantine A. Murenin]

On 17/10/2007 12:45, John Baldwin wrote:

> [Trying to redirect this off cvs-all & friends.. ]
> 
> So as I said previously, I thought about this some more offline last night / 
> this morning and looked at the code some and here are my thoughts:
> 
> Things I like about the current sensors code:
> 
> - I like the actual sensor object used to represent a sensor.  It has a few 
> basic things like a string for a name, a type (I would have just done 
> a "units" for the value, but the type is basically that), and a basic alarm 
> state. (I might have done 4 states, think green, yellow, orange, red mapped 
> to good, warning, critical, bad.  However, the 3 states in the current code 
> is fine.  4 states might be overkill.)
> - I like having the lm(4), etc. sensors report status via an object like this 
> instead of just getting some string out of a tool like 'mbmon'.  A framework 
> should provide the data so that multiple utilities can use it.
> - I'm not entirely opposed to having kernel drivers for various known sensor 
> providers like lm(4), etc.  OTOH, I could see a driver just providing ioctls 
> to query the list of sensors and a sensor's value similar to using requests 
> to the IPMI BMC to request SDR data via ioctls to /dev/ipmi0 as the kernel -> 
> userland interface.
> 
> Things I'm not a big fan of:
> 
> - Forcing all sensors to be in the kernel.  A general rule in most OSes is to 
> minimize the amount of stuff in the kernel.  The kernel is easily the most, 
> erm, "sensitive" process in the system.  A segfault has much more serious 
> consequences in the kernel (panic) than in userland (SIGSEGV).  It also makes 
> it more complicated to add "psuedo" sensors.
> 
> For example, if I wanted a sensor for CPU usage based on the kern.cp_time 
> sysctl, I could easily do that in userland by quering the sysctl 
> periodically, computing the relative % busy and set a status based on a set 
> of trigger points.  Similarly, you could conceive having 
> virtual/pseudo/whatever sensors for disk space, etc.  At some point you do 
> risk duplicating SNMP traps with sensord I suppose.

This is an overengineering, IMHO.  There is no reason to tie 
kern.cp_time with the sensors framework.  kern.cp_time is kern.cp_time.

> 
> I also genuinely think it is better to keep lots of state around in userland 
> rather than in the kernel.  That is, I think the kernel should provide a way 
> to query a sensor (RAID drivers provide ioctls to communicate with the 
> firmware, IPMI has ioctls to allow userland to communicate with the BMC, some 
> drivers may provide ioctl/sysctl/whatever to read sensor values directly), 
> but I don't think we should try to store history (see the cp_time example 
> above) or extended state (keeping track of which drives exist so you can 
> detect a drive that goes away) in the kernel.  That belongs in userland.  I 
> think it can be ok for some sensors to be completely in the kernel and just 
> get queried directly from userland, but I don't think that is a valid design 
> constraint to enforce on all sensors.
> 
> Things I think are dubious at best:
> 
> - That it is more secure to put code in the kernel than as root in userland.  
> It seems odd to even have to mention this, but it should be painfully obvious 
> that a bug in a driver has much worse consequences than a bug in a user app 
> running as root (or even better, some dedicated non-privileged account in a 
> group that can send ioctls to /dev/ipmi0 or other monitored devices).  I 
> guess maybe I can see a viewpoint where you hope that a driver bug always 
> panics and doesn't just corrupt data and so it's more likely to get a SA's 
> attention and be less exploitable maybe?  I can understand that 'mbmon' is 
> untrusted code, but it seems to me that there are some less drastic measures 
> than rewriting it all as kernel code, namely 1) audit the existing code, or 
> 2) rewrite it all as userland code, ideally less privileged.
> 
> Other things that might be nice:
> 
> - IWBN to have a userland interface to sensors.  For example, if nothing else 
> a sensor enumerator rather than duplicating the sysctl loop as the current 
> code does.  This would make it easier to at least adjust the current 
> artificial limit on the number of sensors since only one place in userland 
> would have to change.  (BTW, having an artificial limit on the number of 
> sensors is lame.  This is an example where using the normal way of walking a 
> sysctl tree is superior.  You can lose the entire limit.)  Having a userland 
> interface also makes it easier to have backends that are entirely in 
> userland.

There is no artificial limit to the number of sensors.  Each sensor 
device can have (2^31 - 1) sensors of each type.  The limit that is 
present only affects the number of sensor devices.  As far as I'm 
concerned, this limit is still long to being crossed even in OpenBSD, 
which has so many sensors on server-grade machines.

> - An snmp module that uses the above userland interface to export sensors via 
> snmp.  bsnmp already has a way to load modules at runtime (at least startup 
> time) to add new MIBS.  This would allow remote monitoring of various sensors 
> if people prefer that to having a daemon on the box post alerts.  If nothing 
> else, it lets you add mrtg or rrdtool type graphs of the history of sensors 
> if desired.

Have you seen ports/sysutils/symon?  It already supports NetBSD's and 
OpenBSD's sensor frameworks, and I was planning to submit a patch for 
FreeBSD, but you know how the events turned out. :-)

syrinx@ was also planning to do the snmp part.

> 
> Basically, I think there should be a "real" abstracted interface in userland 
> that can use various backends.  One backend could be to query sensors from 
> drivers that provide them directly (lm(4), etc.).  Another backend could use 
> the existing IPMI interface to query SDR sensors via IPMI commands to the 
> BMC.  Different RAID controllers could provide backends that communicate with 
> the firmware to maintain whatever state is needed, etc. but w/o doing all 
> that in the device driver.  People could write their own custom sensors w/o 
> having to write a kernel module.  Maybe that's a bigger vision than you were 
> shooting for.  I'm not sure phk@ will agree with this one either fwiw. :)

I'd say -- go ahead!  The current FreeBSD port of the OpenBSD's hardware 
sensors framework is very usable and stable as it is.  If people want to 
create some radical FreeBSD-specific changes, they are obviously free to 
do so -- the BSD licence and spirit prevail!  If you want to start from 
scratch, be that so, too.

Linux has "you must install and configure it first" lm_sensors, NetBSD 
has "overengineered in some parts, underengineered in others" envsys(4), 
OpenBSD has the sensors.h framework with "half a hundred sensor drivers 
in GENERIC".  If people have problems with the architecture of this 
framework as it is related to FreeBSD, they are more than welcome to 
design yet another incompatible sensor framework specifically for 
FreeBSD!  Actually, this sounds like the next thing that should be added 
to the ideas page.  :)  Competition only makes us go forward, and I'm 
looking forward to your work!  Unless this discussion is only about 
words, of course.  ;)

Cheers,
Constantine.