> >What you're seeing there is SAF-TE, not SES. X'ing out the vendor is
> amusing-
> >given the ID it's set at: it looks like the 2nd GEM chip on a Sun D1000.
>
> Actually, it was an IBM Netfinity 7000M10.
Just for my curiosity- is it a GEM chip implementation?
> >If there's any interest here in this, I'll finish the ioctl version and
> put it
> >out there for you to play with. I did some toy management tools for
> reporting
> >this information- it's in the FreeBSD 4.0 release in /usr/share/examples.
>
> Looks like a circular argument. No SES/SAF-TE Linux support means
> the enclosures don't need to implement it. If no enclosures implement it
> there is no reason for Linux to support it.
This is a fine argument except that Linux != The_Universe. There are plenty
of reasons for SES to be supported (and it will be) by many devices- it's a
quite flexible protocol for doing things other than just passive monitoring-
you can do a substantial amount of device control with it. In my opinion,
such as it is, no serious RAID, JBOD, or Fibre Switch vendor can get away from
implementing SES. Serial or Ethernet out of band control/info is fine (e.g.,
for SNMP), but the attraction of in band information is high and modified mode
sense just doesn't cut it.
SAF-TE is another story- I suspect thist might whither away. The website that
had the spec for it had been down for months, so I rather imagine that the
original proponents of it have given a large yawn and moved on.
> In the implementations I'm famailiar with, each enclosure would be
> represented by a /dev/sesX (x=0,1,2...) device for the monitoring software
> to play with.
Well, that'd be easy for me to implement.
> FWIW,
> Steve
> (opinions expressed are my own and not those of my current employer)
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
