Re: [PATCH] minimal SAS transport class

[Patrick Mansfield <patmans@us.ibm.com>]

On Sat, Aug 20, 2005 at 12:15:41AM -0400, James.Smart@Emulex.Com 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