On Sat, Aug 20, 2005 at 12:15:41AM -0400, [EMAIL PROTECTED] 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
-
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
