Subject: hardware monitor device drivers / kernel support (eg. LM78)
To: None <freebsd-hackers@FreeBSD.org, tech-kern@NetBSD.ORG, port-i386@NetBSD.ORG>
From: Greg A. Woods <woods@zeus.leitch.com>
List: tech-kern
Date: 06/03/1998 15:52:46
[[ Please feel free to trim out any cross posting as appropriate, but
please do include <woods@zeus.leitch.com> in any replies. ]]

I'm about to embark on adding kernel support for hardware monitoring.

In particular I'm interested in supporting the National Semiconductor
LM78 system hardware monitor that's available on motherboards such as
the ASUS P2L97 and some models of the FIC PA-2012, etc.

It would appear that there are at least three or four ways to approach
the introduction of such functionality in the system, and perhaps
various combinations or permutations of these ways.

First off I should state some overall goals.  Of primary concern is an
ability to generate management alarms (eg. through SNMP) for reporting
exceptions to various limits and interrupts the chip can detect.  Also
necessary is the ability to do trend analysis -- i.e. periodic data
gathering of data values from the chip by a logging agent.  Since at
least the LM78 chip requires some programming to set limits, it's also
necessary to be able to this programming from user land.  It may also be
possible to use at least some of these hardware monitor subsystems to
record log messages (some of the newer ones have some NVRAM, and even
the LM78 has 32 bytes of P.O.S.T. RAM that may survive a simple reboot).

The four primary ways of providing an interface to the hardware monitor
chip that I can think of would be:

	1. minimal character device with ioctl() interface.
	2. full fledged character device with communications protocol.
	3. sysctl interface.
	4. virtual filesystem interface.

Asynchronous alarm outputs could be done either through the character
device interface or a virtual file (with a monitoring daemon process),
and/or through the normal kernel syslog mechanisms.

My preference is to implement this as a virtual filesystem, however in
structure it would be extremely similar to a sysctl interface, and since
I've never really liked sysctl in the first place I'm thinking of
combining these two ideas and simply adding a full sysctl interface to
kernfs, complete with additional support for what could hopefully be a
fairly generic hardware monitor "MIB".

Ideally there should be one or more auto-configured device drivers that
detect and supports the various chips, with a higher level API for the
virtual fileystem to call upon.  I don't know that I'll get too far into
desiging this just yet -- I'll probably do the device detection and
config at mount time in the virtual filesystem for now.

The reason I'm inviting comment is that I'd really like to be able to
submit this code once it's done and let the maintenance be taken over
because I doubt I'll be able to maintain it for more than one or two
motherboards in the future.

I'm also interested to learn if anyone else is working on similar
things.  I've been able to find a couple of lm78 drivers in linux land,
and we've got a small program that when given inb()/out() access can
read values from the lm78.  One of the linux drivers has sysctl and
kernfs support already and I'll probably use it as a starting point.
However I've seen no mention to date of these things in the *BSD
circles.

This work will be done initially for FreeBSD (RELENG_2_2 only, since
that's what we're using), and then soon after (or perhaps
simultaneously) for NetBSD/i386 (with the kernfs/sysctl integration for
all NetBSD variants, of course, and tested on at least sun3, sparc,
pmax, and hopefully alpha).  Since my next server will likely be Alpha
based I'll probably look for a motherboard with something like the lm78
on-board, and so will also add NetBSD/alpha support at that time.

[[ Please feel free to trim out any cross posting as appropriate, but
please do include <woods@zeus.leitch.com> in any replies. ]]

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>