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
--
To unsubscribe from this list: 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
