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

That'd be more like "and"; there are a lot of words there. 8)

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

Understood; there's also a lot of platforms where there are no BIOS 
services per se.  I think I should have been clearer there insofar as 
the point I was attempting to make was that there seems to be no 
winning standard for accessing environmental data.

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

Yes; and dynamism includes boot-time as well as run-time.  This is 
prettymuch a given.

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

No kidding.  I have been watching the DMTF for over 12 months now, and 
they show no signs of flagging.  It may have something to do with the 
undeniable appeal that "lower TCO" and "increased accountability" has 
to people in the managerial arena.

I feel that it's important not to lose sight of this, as failure to 
perform in this area will instantly disqualify you from many major 
markets.

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

The preferred method for moving data out of kernel space is likely to 
vary by platform; even if you were to standardise on the in-kernel side 
of that interface it would be advantageous, eg.

                         +-------+-------+-------+-------+
  parameter access API   | prm 1 | prm 2 | prm 3 | prm 4 |
                         +-------+-------+-------+-------+
  parameter access lib   | platform dependant            |
                         +===============================+
  parameter im/export    | platform dependant            |
                         +-------------------------------+
  parameter abstraction  | platform dependant            |
                         +-------+-------+-------+-------+
  parameter collection   | dev 1 | dev 2 | dev 3 | dev 4 |
                         +-------+-------+-------+-------+
  I/O abstraction        | platform/machine dependant    |
                         +-------+-------+-------+-------+
  hardware               |   1   |   2   |   3   |   4   |
                         +-------+-------+-------+-------+

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

Yup.

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

Yes, although I would tend to expect that the given platforms are 
likely to want a unified mechanism for parameter export.

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

8)

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

Not unreasonable.  I don't think that any of this is going to happen 
terribly fast...

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