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.
lsscsi could do with some help detecting the transport.
It uses an untidy set of heuristics now that can easily
be tripped up by sysfs changes.
It may be helpful to differentiate between a "near end"
transport (i.e. between the initiator and the target) and
the transport (and possibly different command set) that
the logical unit (LU) reports.
Doug Gilbert
--
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
