From owner-freebsd-hackers Wed Jun 3 13:34:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA26072 for freebsd-hackers-outgoing; Wed, 3 Jun 1998 13:34:03 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.mauswerks.net (root@ns.mauswerks.com [204.152.96.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA25986 for ; Wed, 3 Jun 1998 13:33:43 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@gw100.feral.com [192.67.166.129]) by ns.mauswerks.net (8.8.0/8.6.9) with ESMTP id NAA23808; Wed, 3 Jun 1998 13:35:06 -0700 Received: (from mjacob@localhost) by feral.com (8.8.6/8.8.6) id NAA09009; Wed, 3 Jun 1998 13:33:27 -0700 Date: Wed, 3 Jun 1998 13:33:27 -0700 From: Matthew Jacob Message-Id: <199806032033.NAA09009@feral.com> To: freebsd-hackers@FreeBSD.ORG, port-i386@NetBSD.ORG, tech-kern@NetBSD.ORG, woods@zeus.leitch.com Subject: Re: hardware monitor device drivers / kernel support (eg. LM78) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have on my middle burner a environmental services driver to port into both NetBSD and FreeBSD (and possibly linux). It will manage both SES (SCSI Environmental Services) and SAF-TE (see http://www.safte.org). One of the things that has blocked me from just doing it (the driver's been done under solaris for quite some time- I just have to really port it- it's a pretty trivail driver) is I'm not sure what context to report environmental info in- I *know* that it will go to SNMP mib at some point, but I'm sure there are intermediate states that are worthwhile. I was assuming only a character interface that would retrieve SES-like objects (they are quite a number of them- enough to possibly manage most of even a bacplane monitor). I had also been puzzling about how to integrate I2C bus support with this since a number of systems (e.g., the alpha 41000) have I2C support for internal temperature sensors. It sounds like you're doing something related. Is it possible that we could integrate these various sources of environmental (which include both the notion of alarms to be read and reset as well as LEDs to blink, and so on- see under http://www.symbios.com/x3t10 for the final draft SES specification) into one common format so the applications won't have to untangle this? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message