Date: Wed, 03 Jun 1998 15:58:40 -0700 From: Mike Smith <mike@smith.net.au> To: freebsd-hackers@FreeBSD.ORG, tech-kern@NetBSD.org, port-i386@NetBSD.org, woods@zeus.leitch.com (Greg A. Woods) Subject: Re: hardware monitor device drivers / kernel support (eg. LM78) Message-ID: <199806032258.PAA01832@dingo.cdrom.com> In-Reply-To: Your message of "Wed, 03 Jun 1998 15:52:46 EDT." <199806031952.PAA19479@brain.zeus.leitch.com>
next in thread | previous 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. 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 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?199806032258.PAA01832>