> [[ 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.

8)  Joy! The LM78 can be mapped into ISA space, or talked to on the SMB 
(I2C) bus.  It can be mapped at 0x290 (fairly common) or at 0x80 (to 
use the POST RAM).  You also have to deal with the LM75's hung off it, 
as well as the LM79 (new variant) and the Intel Haceta 2 (compatible).

I'm led to believe that the PII processor modules also have SMB
connectivity and internal monitoring of some unspecified sort.

> 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.

Given the diversity of potential monitoring sources, it strikes me that 
using the hardware alarm facilities is perhaps less useful than leaving 
the alarm facilities at a higher level in the abstraction.

> 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.

This would be unpopular with the people that don't like ioctl().

> 	2. full fledged character device with communications protocol.

This would work best in the DEVFS environment, where you could populate 
a directory with nodes for detected parametric sources.

> 	3. sysctl interface.

This is perhaps the best method, but would require adding dyanmic node 
creation to sysctl.

> 	4. virtual filesystem interface.

This is the approach the Linux people have used (in their procfs).  I'm
not sure I like it, and a lot of other people have voiced unhappiness 
about it.

> 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.

I think the daemon would be better placed to deal with policy.  The 
alarm facilities on the Natsemi parts at least are more geared towards 
alerting the SMI BIOS than a "normal" consumer.

> 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.

Given a decent design to start with, I think that'd be relatively 
straightforward.

> I'm also interested to learn if anyone else is working on similar
> things. 

Yes, on a side burner.  I'm mostly working on the Intel SMB (function 3
in the PIIX4), attempting to stick to the SMBBIOS API for a low-level
layer.  You would put the LM7x driver on top of this, for example, as
well as on the ISA bus.

> 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.

The only Linux LM78 driver I've seen was Donald Becker's.  It produced 
some very unrealistic results on the few systems I tested it on, which 
doesn't say much I guess.

I would suggest that we need to consider the provider abstraction(s) 
fairly carefully if the ultimate goal is standards interoperability.  
For better or for worse, the elephants have been down this path 
already.  See www.dtmf.org and www.teleport.com/~acpi for some of the 
footprints.

-- 
\\  Sometimes you're ahead,       \\  Mike Smith
\\  sometimes you're behind.      \\  mike@smith.net.au
\\  The race is long, and in the  \\  msmith@freebsd.org
\\  end it's only with yourself.  \\  msmith@cdrom.com