Re: [linux-usb-devel] [2.6-test] Bug in usb-storage or scsi?

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

On Fri, Sep 12, 2003 at 12:43:14PM -0600, Pat LaVarre wrote:
> 
> > From: Patrick Mansfield <patmans@us.ibm.com>
> > ...
> > last April: ... changes since then
> > in how the MODE SENSE is handled (sd.c only?)
> 
> Anybody know more?

The mode sense 6 vs 10 that James mentioned, search the code for
use_10_for_ms, used in scsi_lib.c, set to 0 in scsi_scan.c and set to 1 by
drivers/usb/storage/scsiglue.c.

> > If you moved a device from one transport to
> > another, the commands sent to the device
> > should not change: for example, you move an
> > iSCSI attached device onto your local system
> > via SPI.
> 
> Eh?

More specifically, if you are using some LLDD or transport X as a bridge
to another transport Y, we might set flags - maybe what commands we can
send - relative to transport X, when they might be inappropriate for
transport Y.

Examples:

If USB (usb-storage) bridged to a remote device that is actually connected
via SPI, today we will try and send 10 byte MODE SENSE commands to the
device.

If iSCSI bridged to a remote USB device, we will only send 6 byte MODE
SENSE commands.

There are also devices that work with FCP or SPI, but those generally
don't have borken devices like the USB storage ones.

> I thought in linux we have competing cdb authors on purpose.  For
> example, how sr decides if a device is writable differs from how ide-cd
> decides if a device is writable.  I thought that the powers that be like
> linux that way.
> 
> No?

> Having multiple cdb authors necessarily means that the cdb's passed thru
> one kind of transport or another do differ any time the multiple
> versions of copy-edited authoring code differ.
> 
> In particular, people designing an unusual device to work with linux
> have to repeat their work: once for sr, again for ide-cd, and so on.
> 
> No?

I don't get your point - I was talking about the transport (LLDD), not the
actual scsi device or upper level drivers.

Code used for different upper level scsi devices should not be duplicated,
I don't know ide or cd enough to comment in that area, except that there
is common cd code (struct cdrom_device_ops).

sr could probably do some of the same things as sd to figure out if a
device is writable, but we are best maintaining current algorithms (don't
have sr send new mode sense commands) to avoid borken devices.

-- Patrick Mansfield