On Sat, Aug 20, 2005 at 12:15:41AM -0400, James.Smart@xxxxxxxxxx wrote: > - the target id is logical for everything but SPI > For FC, target ids are typically assigned to devices on a > 1st-seen-1st-assigned basis. For several reasons, there can be > changes in port discovery order after link events (cable pulls, > etc). For 2.4 kernels, the driver typically maintained a mapping > within the driver to ensure the same device showed up at the same > target id, even if it disappeared for some amount of time. If FC > was the boot device, wacky methods were used to ensure the mapping > persisted boot-to-boot. 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. Printing of them won't be so nice, we should have used hex values in our device's bus_id. Hex would also make scsi class/bus_id shorter. We can in theory overflow it today: (5 digits per short + 10 digits per int * 3 + 3 :'s) = 38 But BUS_ID_SIZE (KOBJ_NAME_LEN) is 20. 8 byte lun would add on another 10 bytes (if in decimal). We generally don't have problems since channel is one digit (it should be a char or bit), id is < 100, and host < 1000 ... lun I'm not sure about: (3 + 1 + 2 + 10) + 3 = 19. i.e. use port_id as the id (8 digits?) and we are more likely to go above 20. -- Patrick Mansfield - : 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
