> As others stated, id is already a tag/label. You should be > able to pass > whatever id you want to scsi_scan_target, like the FC ID > (port_id), and > then we also want an abstract iterator in fc transport for the id for > usage in scsi_scan.c:scsi_scan_channel. Then you can lose all the > fc_host->next_target_id code.
All nice and well, but.... How did this help things ? The issue was the device with a changing target id. If the device comes back at the same address each and every time, ok. But, with FC, the Port ID is temporal. It can change on a loop init, fabric reconfig, or with a user cable swap (kicked the cable and replugged). If the port id changes during run time, what are you to do ? What if a new port is seen at the old port id, how do you now deal with the name conflict ? You know apps are going to key off the physical bus address being the target - if it changes, this becomes very problematic. This approach only works as long as the transport's id fits within the target id (an int). How would the SAS address(8byte wwn) utilize such a scheme ? -- james s - 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
