Date: Wed, 03 Jun 1998 14:34:29 -0700 From: Mike Smith <mike@smith.net.au> To: Matthew Jacob <mjacob@feral.com> Cc: 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) Message-ID: <199806032134.OAA01436@dingo.cdrom.com> In-Reply-To: Your message of "Wed, 03 Jun 1998 13:33:27 PDT." <199806032033.NAA09009@feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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). Environmental and power control issues are becoming big business it seems. Starting at the top with DMI (www.dmtf.org) and going down, there's a large model forming. Do you plan to work within this, or do you have an alternative framework in mind? > 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. The I2C thing has been somewhat of an issue for me - many PC motherboards (eg. everything with a PII onboard) have an I2C variant (SMB). Unfortunately, the SMB BIOS doesn't seem to be widely implemented, so there's no precedent for a set of primitive bus services there (only the SMB I/O in the PIIX4). For your parametric retrieval, depending on the messaging style you might want to consider: - DEVFS node (not really portable outside FreeBSD AFAIK). - sysctl node (may be problematic if you want to dynamically create nodes at runtime, unless you handle your own traversal). - socket, cf. PF_ROUTE. This would involve creating a new event reporting facility (PF_EVENT) and assorted infrastructure. It sounds like you're looking at two of a set of environmental services (others eg. S.M.A.R.T.) which should be coordinated within a unified framework. DMI offers this, although at the cost of some (!) extra complexity. I'd be very interested to hear others' opinions on the relevance of DMI and the work of the DMTF. Note especially the advanced state of DMI : SNMP mapping techniques they recommend, if you are concerned about SNMP interoperability. > 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? "yes". 8) I would think that would be more than worthwhile. -- \\ 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?199806032134.OAA01436>