IAM ====== Name: SCSI SAS 1275 Binding Submitter: conrad.turlik@sun.com Owner: Sunit Jain Intern: Narayan Venkat Interest: Eduardo.Horvath@sun.com Status: inception scheduled 02/04/2008 Exposure: closed Comment: SUMMARY ======= SAS bindings need to be standardized and the interfaces documented for client programs to identify and access SAS controllers. This is needed to shift from the existing implementation of client programs identifying disks by their target id's, to using their SASAddress or PhyNum. Additional issues in addition to issues list: Chris - As a rep for Solaris we have a divergence in regards to need for initiator port recognition. Hitendra - There were some discussion once the case was filed. Were they all addressed? A: The issue that Chris raises is the meta issue. Other issues were responded via email. Eduardo's issues are not listed in the issues file. They were sata device related. David - There is something about n form of addressing that I'm not familiar with. ISSUES ====== Issues for inception review -- dmk-1 Need more info on the synthetic address format for sata devices. (How is it constructed, why is it guaranteed to be unique?) =======>Project Team: Global unique identifer is required. It is not guaranteed to be unique by the spec. By convention it is using serial and model number; this should be good enough. DKhan: Call out the specific formats and descriptors from p 83 that you are dependent on. dmk-2 I still don't understand the PP,lun form of the unit address. - How does the phy + lun uniquely identify a target? Shouldn't it be PP,w[,lun] ? =======>The phy number gives direct connection to the device. This is for point to point connection. The P number is used. Doesn't work for expanders. Little less unstable than fiber channels. 3.1.1.22 David Khan to email suggestions for wording in this section. - I'm not sure that the phy# makes sense in the unit address. When I read the sas spec, it said that sw can assign phys to ports in different ways and the same phy can be used with one or more ports. Doesn't the logical port number make more sense from both a connectivity point of view and a user-friendly point of view? In either case, if the admin changes the configuration of the port, the pathnames can change. Either way is not particularly friendly since there doesn't seem to be a way to label port numbers on the connector. dmk-3 Is there a transition plan for existing sas firmware and OS drivers? Are we actually going to change the way that existing sas devices already in the field report themselves and create problems for the user and the OS in this case? This needs to be considered and covered. For plug-in devices, I would imagine that they would continue to behave as they do today, unless the admin decides to upgrade the firmware on the plug-in card. For on-board devices, we probably need to make sure that we're not just arbitrarily changing the behavior of existing devices unless the admin decides that they want to do that since the device pathnames and drivers will change. How will the project manage this? =======>Existing systems using SAS get this, it is going to screw up everything. We are not going to upgrade. The README of the patch will have clear instructions & provide a new Solaris driver. What about the case of a drop in driver: mother board device without fcode on it. At the obp, existing platform will keep the existing behavior or be backward compatible. Make it a separate include. Ensure FWARC that it is being resolved with OPP team and release engineering. Project Team: look into n form of addressing for SAS 2.0 & determine whether we want to use it. Other issues: These do not have to be resolved today. 1. Paragraph 2 does not explain how conversion from pg 83 logical unit name is happening. 2. We are doing something different from the OS. What is mpx io doing? Why isn't mpx io being used? 3. Whether to use port address or not. 4. Whether vendor id makes up the synthetic address format. Is the section even needed? Chris - valid configs are defined by SAS X in which we end up with mulitiple paths to the same SAS address. OBP to choose a given port. When it comes to Solaris we need to manage the port and direct traffic to a given path - by selecting the initiator port and transport address relative to the initiator port. This would be a major divergence from Solaris. ========>Chris to write a minority opinion and include areas of divergence: ie, when setting up boot devices back to OBP to set property values. THE NEXT STEP ============= dmk-1: Call out the specific formats and descriptors from p 83 that you are dependent on. Other issues: These issues need to be captured. They do not have to be resolved today. 1. Paragraph 2 does not explain how conversion from pg 83 logical unit name is happening. 2. We are doing something different from the OS. What is mpx io doing? Why isn't mpx io being used? 3. Whether to use port address or not. 4. Whether vendor id makes up the synthetic address format. Is the section even needed? dmk-2: look into n form of addressing for SAS 2.0 & determine whether we want to use it. Which specific versions of SAS should this apply to. Chris to write a minority opinion and include areas of divergence: ie, when setting up boot devices back to OBP to set property values.