Mike Smith wrote:
> 
> > 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?


I hadn't gotten that far- but I hadn't charged ahead just for the reason
that I know that this is grown very big very fast. The DTMF model may
not address some large server system issues- I don't know it very well
(I'll read the specs today or tomorrow).


> 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).

There's a lot I2C supprt that is not BIOS managed.

> 
> For your parametric retrieval, depending on the messaging style you
> might want to consider:
> 
>  - DEVFS node (not really portable outside FreeBSD AFAIK).

Yup.

>  - sysctl node (may be problematic if you want to dynamically create
>    nodes at runtime, unless you handle your own traversal).

We have to plan for dynamic- if you support dynamic addition/deletion
of devices, you must also plan for devices that manage environmental
data as well. Let's say we handle (as we should and will) SCSI devices
dynamically attaching and detaching- well, there you'll have
environmental
devices coming and going.

>  - 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.

Yes- this may be the way to go, although I had a more practical and
immediate concern about how to get support in, even partial support,
as quickly as possible with an eventual goal to have a unified
management
schema. Clearly this thing is much bigger than I thought.

I would prefer an ioctl interface since that eases porting across all
the unix variants (they all have ioctl- only FreeBSD has DEVFS, only
*BSD has sysctl, only Linux has that sexy procfs way to get info)- but
this may in fact be not that important if you add an additional user
layer that handles the collection of data and presents objects upward.
The amount of data involved is small, and the real time constraints
are not onerous.

One of the implications then of doing this is that we don't:

	a) have to agree how to collect the information (from platform
	to platform)- that's for that platform's implib to deal with.

	b) The actual kinds of data sources can be ad hoc and don't
	*have* to present unified information objects- the implib
	can translate.

Hmmm- I think I've argued myself around to *not* having a unified
set of services at a lower level- typically device driver writer's
reaction- punt it to a higer level...

I'll mull over all of this a bit more and see whether I can propose
something more- but really, truly, I'll be putting in the SES/SAF-TE
driver very soon- I need it for some other projects!