Re: [PATCH] RESEND: SCSI, libata: add support for ATA_16 commands to libata ATAPI devices

[Douglas Gilbert <dougg@torque.net>]

James Bottomley wrote:
> On Thu, 2007-02-01 at 04:54 -0500, Jeff Garzik wrote:
>> Agreed... but that doesn't make it the /right/ thing to do ;-)
>>
>> The logic behind the current code, which limits to the maximum size 
>> allowed by an attached device on the port, is mainly to leverage the 
>> SCSI layer as a filter for bad CDB lengths.
>>
>> IOW, it's called "being lazy" ;-)
> 
> But you're requesting code changes in the SCSI layer because of this
> incorrect usage.  max_cdb is supposed to be the *host* limit.  The mid
> layer finds out and respects device limits separately from this.

To be more pedantic:
  actual_max_cdb = min(MAX_COMMAND_SIZE, host_limit)

Since the host is a bridge, that could be a limit on
near side (i.e. PCI (unlikely)) or the outer side (i.e.
transport initiator (port)). In modern HBAs the
host_limit is likely to be greater than 16, to allow
for advanced SBC and OSD commands. However currently
MAX_COMMAND_SIZE (defined in scsi/scsi_cmnd.h) is 16.

It is the ATAPI _transport_ that has the 12 byte cdb
limit *** (at least according to MMC-5 rev Annex A;
is S-ATAPI any better?).
Other MMC transports referred to in MMC-5 are
SPI, SBP(IEEE 1394) and USB mass storage; and no mention
is made of cdb length limits for them. Since ATAPI is
the dominant transport for cd/dvd drives, MMC doesn't
define any commands over 12 bytes in length, but both
SPC (which MMC should honour) and SSC-3 (think tape
drives, ATAPI connected) do.

My point is that the linux block layer and scsi mid
level should get out of the business of putting hard
limits place. Why?
Since kernel limits are at best necessary but not
sufficient, the upper layers still need to be able to
cope with errors associated with that limit.
So why have the limit?
Does the kernel do analysis to find out whether a USB
connected DVD drive has a USB to ATAPI bridge externally?
I don't think so. There is a role to fetch information
that may act as a guide when a ULD has a choice of commands
to build (e.g. sd deciding between READ(10) and READ(16)).
Let the cdb size bottleneck (or whatever) report an error
and upper layers that are impacted, including user space
programs, can act accordingly.

If the kernel really wants to offload complexity to the
user space, the kernel needs to get out of the business
of trying to foresee errors. It needs to get better at
coping with errors and if possible adapting its behaviour.


*** not the host nor the device

Doug Gilbert