On Monday, March 06, 2006 9:39 AM, James Bottomley wrote: > > Well, it's not ... the nexus loss timeout parameters weren't > available. > The intent is to embed the rphys into more representative structures > that can have different parameters (an expander has parameters than an > end device doesn't and vice versa). Eventually, when the whole lot is > converted, the ability to alloc a plain rphy will be revoked and > everything will be done via the real device type. > Christoph mentioned in other email about adding sas_end_device, sas_expander, and sas_sata_device, which is fine. I'm interested in the changes you forsee, as we need to make plans for that in mptsas. As long as these changes are not breaking the driver.... > The aic94xx needs a full tree representation for this, so I'm planning > to add this to the sas transport class. We really need to work out a > way for mptsas to display the tree too. Having different > topology views > for the same physical SAS topology show up when you change > HBA is a bit > undesirable. > Agreed. We need to display same tree. > Yes, I know. However, I need expander devices that contain the > necessary information to be able to perform discovery in the sas > transport class, so they'll appear eventually in the same way > that this > patch adds end devices ... as objects with embedded rphys. > Ok, define discovery. I hope that doesn't mean the transport layer is sending SMP passthru commands to the driver? Recall, concerns from our architect over the performance hit? They recommend to me that we providing the topology data via config pages. - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
