> ENVSYS API 1.0

Cool.  I think this is something that needs to be done, and I'm glad to
see that someone's working on it.  Like Matt Jacob, I'm interested in
seeing this extensible to SAF-TE and the SES.  Unlike Matt Jacob (I
expect), I know very little about these yet (I'm just getting into
them for a project that I hope to see come to fruition in the next 6
months or so).

Looking over the API, I'm struck some at how this is in some ways
similar to the audio devices in that we want to describe a fairly
wide variety of similar things (i.e., fan speed, temperature, current,
voltage, etc.) for some set of hardware (perhaps a CPU and CPU fan,
perhaps 12 fans + 5 power supplies + 4 CPUs&fans + AGP fan, etc.).

Would it make sense to extend this to something more like the audio
model where an underlying device driver (or drivers) can register
capabilities with a general driver and have that general driver provide
the interface to userland?

I've only had a fleeting introduction to audio stuff so far, and (as I
said above) I'm just starting to enter the SAF-TE/SES world, so it's
quite possible that I'm off-base here.

I'd actually like something even more universal, though, instead of
having different spaces for each device (as in audio), I'd like to
see a unified view of all of the environmental sensors available in
the system.  If the device can register with a locator, it could be
something analagous to the bus/device system or even a filesystem:

	mainbus0/cpu0
		temp (value)
		fanspeed (value)
(or  cpu0/temperature (value)
 and cpu0/fan0/speed (value))
	mainbus0/cpu1
		temp (value)
		fanspeed (value)
	mainbus0/agp0
		temp (value)
		fanspeed (value)
	scsibus0/ses0/ps0
		status  (set: online, offline)
		current (value)
		voltage (value)
	scsibus0/ses0/ps1
	etc... (apm could/should? have a module that could provide an
		interface for its information)

Perhaps this is too ambitious for version 1.0?  Or is it (or something
like it) even a good idea at all?

I'd also like to see a general extension for this to include kernel
events firing on reception of interrupts of various types.  I.e., if we
receive an asynchronous select from an SES device that it is using to
report the loss of a drive on an array or one of its power supplies or
some such, that should trigger an event that should be caught in a way
similar to a battery low event on a laptop or a CPU over-temperature
alarm or anything else .  Of course, I would want to be able to hook
different daemons or userland programs to the "tree" to pick up different
events, or be able to supply a do-everything monitor.

I wish I was a bit further down the learning curve right now (or at home
in front of some documentation instead of on the road, relying on memory
of a quick skim through some docs) to provide a more coherent and/or
complete proposal.

Cheers,
-allen