Porting OpenBSD's sysctl hw.sensors framework to FreeBSD

[Robert Watson]

On Wed, 11 Jul 2007, Poul-Henning Kamp wrote:

> In message <469420B9.20401 at FreeBSD.org>, "Constantine A. Murenin" writes:
>
>> If you want to have no such framework that could potentially diagnose or 
>> predict system failure, it's your choice, [...]
>
> I would love to have that, but the OpenBSD code isn't that.

In the general spirit of SoC, I would suggest that a more constructive line of 
commenting might come with suggestions, not just rejections :-).  Are you 
arguing that the current proposed framework offers little incremental benefit 
over simply having the sysctl framework in the first place and having each 
source of information (i.e., device driver) just export it directly?

It seems clear that people would like all these measurements to be available, 
even if not by the precise mechanism proposed.  So far the specific technical 
criticals have been:

- There's such a diversity of motherboard devices and probe mechanisms that
   any kernel driver would become rapidly over-burdened and needlessly
   complicated.

This doesn't argue for doing nothing, just that perhaps a kernel device driver 
is the wrong place.

- A moderate number of user space tools exist to do this already in the ports
   collection, and user space is the right place to do this as it doesn't need
   to be in kernel.

Part of the argument here has to do with code becoming stale, and one possible 
outcome of a more actively maintained in-OS framework is that it is better 
maintained, and that code is shared across platforms.  Also, I have to say 
that I don't run monitoring tools on several of my boxes because I can never 
figure out which are the right ones to run, and the ones I try inevitably 
don't work.

- This service is redundant with respect to existing IPMI interfaces, and that
   perhaps the IPMI interfaces are preferred as they interact better with
   simultaneous ROM flashing, etc.

Undoubtably true.  However, the proposed sensor framework isn't just about 
motherboard monitoring, but also about monitoring a range of devices, and if 
you've never struggled to get IPMI to just work on a box then you haven't used 
IPMI :-).

It seems you have a more structural argument, but I think the nature of that 
argument will become more clear if you say what it is you'd like to see in 
terms of an alternative approach.

Robert N M Watson
Computer Laboratory
University of Cambridge