I like this all... only comment:

> 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

SES/SAF-TE are passive devices. But a driver timeout can poll them
regularly. Sometimes SES is a passthru capability (i.e,  a bit in INQUIRY
data says that the device in question groks SES commands), and sometimes
it's a device type (0xd). 

I'd also like to point out that SES/SAF-TE provide also provides *control*
functions as well as monitoring functions. You can command leds on/off,
prepare for insertion/removal, etc. Each device type has device specific
values (like temp for thermometers, voltage for power supplies, SCSI ID
for disk drives...).

SES Data structures are self-describing (being derived from the SCSI mode
page data approach) and can also be grouped into subenclosures.

The API I did for Solaris for SES/SAF-TE was to provide a pretty simple
set of ioctls (essentially):
	
 How many SES objects are managed by this device instance?
	Get me the map of Objects to Object IDs (contains object type)
	Get me the status of Object ID #X
	Set the status of Object ID #X

Or:

ultpak > root getnobj /dev/es/ses0
/dev/es/ses0: 15 objects
ultpak > root getobjmap /dev/es/ses0
/dev/es/ses0: 15 objects
 Object 0: ID 0x0 Type 'Device'
 Object 1: ID 0x1 Type 'Device'
 Object 2: ID 0x2 Type 'Device'
 Object 3: ID 0x3 Type 'Device'
 Object 4: ID 0x4 Type 'Device'
 Object 5: ID 0x5 Type 'Device'
 Object 6: ID 0x6 Type 'Device'
 Object 7: ID 0x7 Type 'Device'
 Object 8: ID 0x8 Type 'Device'
 Object 9: ID 0x9 Type 'Device'
 Object 10: ID 0xa Type 'Device'
 Object 11: ID 0xb Type 'Device'
 Object 12: ID 0xc Type 'SCC controller electronics'
 Object 13: ID 0xd Type 'Nonvolatile cache'
 Object 14: ID 0xe Type 'Uninterruptible power supply'
ultpak > root getobjstat /dev/es/ses0 0xe
Object 0xe: 0x1 0x0 0x0 0x0
...

Or a summary, which includes overall status of the enclosure

ultpak > root getencstat -v /dev/es/ses0 
/dev/es/ses0: Enclosure Status <CRITICAL>
Device Element(0): OK (Status=ok (bytes=0x01 0x10 0x40 0x00))
Device Element(1): OK (Status=ok (bytes=0x01 0x20 0x40 0x00))
Device Element(2): OK (Status=ok (bytes=0x01 0x11 0x40 0x00))
Device Element(3): OK (Status=ok (bytes=0x01 0x21 0x40 0x00))
Device Element(4): OK (Status=ok (bytes=0x01 0x12 0x40 0x00))
Device Element(5): OK (Status=ok (bytes=0x01 0x22 0x40 0x00))
Device Element(6): OK (Status=ok (bytes=0x01 0x13 0x40 0x00))
Device Element(7): OK (Status=ok (bytes=0x01 0x23 0x40 0x00))
Device Element(8): OK (Status=ok (bytes=0x01 0x14 0x40 0x00))
Device Element(9): OK (Status=ok (bytes=0x01 0x24 0x40 0x00))
Device Element(a): OK (Status=ok (bytes=0x01 0x15 0x40 0x00))
Device Element(b): OK (Status=ok (bytes=0x01 0x25 0x40 0x00))
SCC controller electronics Element(c): OK (Status=ok (bytes=0x01 0x00 0x00 0x00))
Nonvolatile cache Element(d): Status=critical (bytes=0x02 0x00 0x00 0x00)
Uninterruptible power supply Element(e): OK (Status=ok (bytes=0x01 0x00 0x00 0x00))

(This is an A1000 with a roached NVRAM).


This was a lot less ambitious than what is being talked about here. It
would be way cool if what's being talked about is implemented. The locator
information *could* be possibly used to give what I considered the crucial
missing piece for Solaris- physical topology. Since *BSD can wire things
down, locator info can be used to construct a physical topology such that
you can say "The fourth fan from the left is bad- replace it...".

-matt