Date: Wed, 3 Jun 1998 15:52:46 -0400 (EDT) From: woods@zeus.leitch.com (Greg A. Woods) To: freebsd-hackers@FreeBSD.ORG, tech-kern@NetBSD.org, port-i386@NetBSD.org Subject: hardware monitor device drivers / kernel support (eg. LM78) Message-ID: <199806031952.PAA19479@brain.zeus.leitch.com>
next in thread | raw e-mail | index | archive | help
[[ 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> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806031952.PAA19479>