In message <19991110010625.I24099@canolog.ninthwonder.com>, Allen Briggs writes:
>> 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).

I'm still unable to retrieve the SAF-TE bits.  Is it accurate (Matt?)
to say that what is being advocated is to make ENVSYS 1.0 return data
and accept configuration in an SES-like manner? (i.e., every device must
accept SES commands and return results using the data structures described in 
ftp://ftp.t10.org/t10/drafts/ses/ses-r08b.pdf)

To be honest, we weren't being that ambitious.  The API has the lmXX
series chips in mind-- a blob of registers hooked up to an ADC.

>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)
> [...snip...]

Many environmental sensors have no idea what physical phenomenon is
attached to a particular ADC.  This sort of structuring is necessarily
provided by userland.

One imagines this API driving a systat-like program; polling the devices
which support ENVSYS 1.0 at regular intervals and using the strings
associated with each sensor as a column heading.  Devices which are aware
of what physical phenomena are attached to a register will provide
reasonable default strings; for the others, a userland configuration
utility to load the strings at boot time can be provided.

>I'd also like to see a general extension for this to include kernel
>events firing on reception of interrupts of various types.

Agreed, but we currently don't have kernel events.  This sort of thing
can be accomplished by a userland daemon however, as you suggested.

-wps