On 05/27/05 02:45, Douglas Gilbert wrote: > In a) the interconnect is SATA. Still it is hard > to believe that the SAS HBA LLD would belong to > anything other than the SCSI subsystem (since > SAS HBAs come with 4 or 8 phys, others of which could > be in scenario b) and/or connected to SAS disks). > Hence the initiator_ports/phys/target_ports on and > seen by that SAS HBA should (also) have SAS transport > classes. It should register with the SAS transport class, where the SAS discover "function" is. The Discover function would find out what is out on the domain and "register" it with the proper "transport" (a more correct way to put it there is). For SSP devices that would be a "scsi disk", for SATA devices that would be a "libata disk" or something like this. The LLDD would either get a CDB for SSP, or taskfile for STP, and pass it along to the hardware. > When a SAS HBA phy is not connected to anything is it > a member of a SAS transport class or a ATA transport > class (or both)? Quite possibly both: SAS transport class, since it is a super class in meaning that the Discover function is in there. > In scenario b) the left interconnect is SAS and the > right interconnect is SATA. The SAS_expander contains > the STP<->SATA bridging function (and, for sake of > argument, no SCSI-ATA Translation (SAT) layer). > Would scenario b) also have a ATA transport > class? I'll assume it does. To be discovered it also Yes it would. As far as the class is concerned it is a SATA device -- how you get to it (direct or through an expander) is the LLDD/firmware/Host Adapter concern. > needs a SAS transport class. Larger enclosures are > likely to be amplifications of scenario b). The presence > of the SATA disk in scenario b) will be discovered via > the SAS SMP (i.e. talking to the SAS_expander) or via > the SES protocol (i.e. a SCSI Enclosure Services target > running near the SAS_expander). Either way if there are > a lot of SATA disks then they are likely to be held > in their initialization sequence to stop them spinning > up all at once. SAS transport intervention may be > required (staggered timers are another possibility). Yes, spinup-hold states would be managed by the Discover function, or by the FW on the expander/ses device. BTW, very nice to mention SES devices. We'll have to bring that up more as they'd be very much en vogue with expanders. > Now I may be wrong but I think that one of the SAS HBAs > that I have read about that looks (externally) like > scenario a) but is actually scenario b). In other words > the SAS_expander is silicon on the HBA and it is not > controlled via the PCI bus, but rather by SMP. I know of such a SAS HA (Host Adapter), and from what it seems the role of the expander-on-chip is to simulate a larger number of phys than actually/physically supported by the HA. By design, this should be transparent to the Discover function, and if it is not, I believe the Discover fn. would do the right thing (i.e. treat is as an expander). > This suggests to me we would need an ordered sequence of > transport classes. I really wonder about trying to model > this level of complexity in sysfs, plus the nightmare of > keeping state data of (topologically) distant nodes up > to date. At some point one needs to supply a management When a SSP talking device is found it is registered as a "scsi device". When a STP talking device is discovered (directly attached or elsewhere) it would be registered as a "libata device". > pass through and hand the problem over to the user > space. The question is, at what point. I'm not 100% sure about user space. The Discover function is pretty straightforward, and simple. Plus the root/bootable device could be a SATA device on an expander or even deeper in the domain. Thanks, Luben - : 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
