Re: RFC: Transport identifier

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2009-02-25 at 23:31 -0500, Martin K. Petersen wrote:
> There are a few cases where it would be useful to know which transport
> is associated with a scsi_device.  For instance when determining whether
> to send a READ CAPACITY(16) to a device or not:
> 
>     static int sd_try_rc16_first(struct scsi_device *sdp)
>     {
> 	if (scsi_device_transport(sdp) == SCSI_TRANSPORT_USB)
> 	   return 0; /* Run screaming for the hills */
>     [...]
> 
> This patch implements support for a transport identifier in the
> scsi_host.  The id defaults to SPI and it is explicitly overridden in
> the host templates for FC, SAS, USB, etc. drivers.
> 
> It also looks like the availability of this transport id could improve
> the sysfs parsing in lsscsi.

I'd really rather not put transport specific knowledge back into the
mid-layer ... the whole idea of the transport classes was to take it out
as much as possible.

The other thought is that a lot of devices nowadays are bridged (all
SCSI DVDs have SPI to ATA bridges; a lot of high end USB storage or
enclosures has USB to ATA bridges), so a single transport identifier
doesn't quite cover it.

The final thought is that a lot of what you're looking for is actually
in the PROTOCOL field of a VPD inquiry, so it might be possible to use
that to obviate a lot of this.

James