I'm annoyed at SES2 section 184.108.40.206
By jmcp-Oracle on Dec 14, 2007
One of the things I'm working on at the moment is a firmware flashing utility. We've got an existing one in Solaris, called fwflash(1m) and one thing that PSARC made very clear is that They don't want a proliferation of firmware flashing utilities inside Solaris. So I'm working on making fwflash(1m) pluggable.
There's a good deal of work required to make this succeed, mostly in the implementation of a plugin interface, and a specific plugin for the area that has a requirement I need to solve.
That requirement pretty much mandates the use of SCSI Enclosure Services-2 (SES2), which is all good and well except when we get to section 220.127.116.11 which deals with the Additional Element Status descriptor protocol-specific information for SAS. I'm particularly annoyed at sections 18.104.22.168.3 (SAS Expanders) and 22.214.171.124.4 (SCSI Initiator Port, SCSI Target Port, Enclosure Services Controller Electronics).
The problem is that - as far as I can see, after about a week's worth of serious and detailed investigation - these sections overlap in how they deliver a data payload to you. So figuring whether you've got a SAS expander, or one of a SCSI Initiator Port, SCSI Target Port or Enclosure Services Controller Electronics is actually incredibly difficult.
I could punt and look at the size of the data payload, except that there'll be cases where Expanders vs (the rest) will coincide in terms of payload size. Or I could assume that everything I see there is an Expander - which would be wrong. Or I could do a massive amount of extra engineering in order to approximate what is probably the answer. Or I could use a lookup table to match against the devices which I really want and need to get access to. Right now, the lookup table is winning - a fact about which I am \*not\* happy.
So, what used to be elegant code in my first prototype is now quite ugly. I'm not happy about it, this vagueness in SES2 has kicked my schedule around and has caused sleepless nights while trying to figure out a way forward.
The SCSI family of standards are normally very well defined, very clear, and precise. I'm not impressed with SES2, that's for sure.