On Feb 10 Chris Boot wrote: > To me it feels like SBP-2/3 wanted the Unit_Unique_ID to be the > identifier by itself No; section 7 is clearly worded that Unit_Unique_ID is optional if the unit is attached to one link only (99.9999382% of all cases in practice, I have checked ;-) but mandatory if the unit is attached to two or more links. In that latter case, Unit_Unique_ID shall be equal across all these links ( = nodes) for a given SBP unit. This makes me wonder, actually. SBP-3 explicitly says that this ID really is the Target Port ID. This implies that all 1394 links via which an SBP unit can be reached belong to the same SCSI Target Port, doesn't it? A more intuitive approach would be if each 1394 link represents a separate Target Port, so that an SBP device with multiple links is a multi-port device, supporting multipathing with several 1394 paths. However, SBP-2 and even SBP-3 were obviously written before --- or without regard of --- SAM's and SPC's multipathing provisions. > (falling back to the node's GUID if that entry was not present), Yes. > but SAM seems to ignore the Unit_Unique_ID and go for a combination > of the node's GUID and the Directory_ID as would have been by > IEEE-1212's design. SAM does not refer to Unit_Unique_ID vs. Node_Unique_ID in particular. These are IEEE 1212 details which concern the transport layer spec SBP-2/-3 but not the SCSI architecture model. SAM merely says that this part of the target port ID is an EUI-64, which is true for IEEE 1212's Unit_Unique_ID and Node_Unique_ID likewise. > There is also an added difficulty in that a directory can't be added to > a single card's Config ROM in Juju, but instead is added to all cards on > the system. This limitation is of course only there to keep management of the Configuration ROM images simple. The KISS principle was central to the creation of the drivers/firewire/ stack as an alternative to drivers/ieee1394/ of Linux 2.3...2.6. But if you want to offer the ability to expose an SBP target only on selected links instead on all of them, we should add the necessary code to firewire-core. -- Stefan Richter -=====-===-- --=- -=-== http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
