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

[Pat LaVarre <p.lavarre@ieee.org>]

> I don't get your point ...
> 
> Code used for different upper level scsi
> devices should not be duplicated, ...

Re whether a pdt x05 dvd/cd device is writable, I think I see
duplication among ide-cd, ide-scsi, and sr.  I hear ide-scsi is dying,
but that ide-cd and sr plan to continue competing.

For example:

sr.c get_capabilities decides CDC_DVD_RAM and cd->device->writeable by
fetching & parsing as raw hex the 2Ah Capabilities mode page via
scsi_lib.c scsi_mode_sense of page x2a, sending op MODE_SENSE = x1a or
MODE_SENSE_10 = x5a.

ide-cd.c ide_cdrom_probe_capabilities decides CDC_DVD_RAM (also stored
as CDROM_CONFIG_FLAGS(drive)->dvd_ram) by fetching & parsing as a
asm/byteorder.h packed struct the 2Ah Capabilities mode page via
ide_cdrom_get_capabilities via cdrom_mode_sense of page
GPMODE_CAPABILITIES_PAGE = x2a, always sending op GPCMD_MODE_SENSE_10 =
x5a.

Neither yet proceeds to try op 46h GET_CONFIGURATION to discover the
other six writable mmc profiles.

> talking about the transport (LLDD),
> not the actual scsi device or upper level drivers ...

Thank you for your patience, sorry at first I did not understand how
narrowly we mean "transport" here.

> use_10_for_ms ...
> set to 0 in scsi_scan.c ...
> set to 1 by drivers/usb/storage/scsiglue.c ...
>
> transport X as a bridge to another transport Y,
> flags ... maybe what commands we can send ...
> relative to transport X,
> when they might be inappropriate for transport Y ...
> Examples ...

Clear to me now (and cool) thank you.

> I don't know ide or cd enough ...
> except ...there is common cd code (struct cdrom_device_ops).

Aye, helpful.

Pat LaVarre