> 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