Hi guys,
Q: I've been wondering how exactly does the transport class work? Can anyone give an intro on attribute container, attribute group, transport class template, etc. I've been looking at those but not 100% sure I understand it all. It looks similar to the old scsi detect "discovery" but not 100% sure.
Q: Also I'd like to ask if domain discovery would be performed by the mid layer? I assume yes, so that "there is no code duplication".
Q: In this case would it be safe to assume that we need a sas_phy, sas_port and sas_ha? A la:
sas_ha 1<---* sas_port 1<---128 sas_phy * ^ | | 1 128 | +-------------------------------+
With the appropriate linked lists and properties as defined in the SAS 1.1 spec ch 4? (undoubtedly more properties would be added as drivers come along)
Now, I can see that there exist scsi_target and scsi_host which appear to be the underlying objects for the transport classes of sorts, host and target.
Q: Since a SAS mid layer discovery core would manipulate ports and phys, do we need to represent those with scsi core objects, or would struct device plus the SAS specific object class suffice?
Q: Also, how exactly would a LLDD register the objects with the class? Would the answer to this be the trivial answer, or is there some kind of "it will detect it itself".
On top of this we would have scsi targets in this picture which would depend on phys/ports/ha. (And LUs depend on targets.)
So basically, would scsi core need to have an internal SAS domain topology representation (how about expanders...). That is, it would help multipathing a great deal.
Thanks,
Luben* Where,
objA N<---M objB, means
objA depends on objB* and objA can associate M number of objB
and objB can associate N objA, where an association is a relationship defined appropriate for the object tuple, which
need not necessarily be homogeneous.
- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
