Re: [example PATCH - not for applying] exclude certain commands

[Luben Tuikov <tluben@rogers.com>]

Matthew Dharm wrote:
> On Sun, Apr 27, 2003 at 10:41:45AM -0500, James Bottomley wrote:
> 
>>So the algorithm is quite simple: you get the command length from the
>>group (using a table with one exception for the 32 byte commands), and
>>then extract the transfer length from the command
> 
> 
> I'm with you up to about this point.
> 
> So tell me how many bytes my command wanted to move?  READ_10 specifies the
> transfer length is 'blocks'.  How many bytes are in a block is
> device-dependent.
> 
> Some commands (i.e. INQUIRY) specify transfer length in bytes.  Others
> (i.e. READ_10) specify it in blocks, and the size of a block is not known
> based simply on the current command.

Matt,

You cannot really constrict yourself to the CDB only.

As a transport/interconnect (what a LLDD is, as well as USB Storage)
you get an Execute Command remote procedure call, in SCSI Core this
is represented by struct scsi_cmnd.

Execute Command rpc contains all that the transport/ic needs in order
to deliver the command to the device server (who will execute the
CDB) and perform (the interconnect) the data transfer.

The reference you want to take a peek at is SAM-3r6, 5.1 --
this is what USB storage is working with, not just the CDB.

Now, you've been talking about the Data-Out buffer size.
This is either ALLOCATION LENGTH (normally bytes), or
TRANFER LENGTH (READ/WRITE, normally blocks).

The reference here is SPC3r12, 4.3.4.4 Transfer Length and
4.3.4.6 Allocation Length.

Please note that Data-Out buffer size *is* the
Expected (maxumum) Data Tranfer Length, the device
server may tranfer less data, (request_bufflen, bufflen).
This is what the standards specify, and what SCSI Core
sets it to.  The actual memory buffer may be bigger.
The device server may transfer less data, but not more.
The device server will NOT modify the returned data
to reflect the insufficient data-in buffer.

So to repeat what the standards say and what SCSI Core
does: sr_bufflen, request_buflen, buflen *is* the
Expected (maxumum) Data Tranfer Length:
	- when it means Allocation Length it is the
maximum available space (e.g. IQUIRY, Request Sense),
(The transport CANNOT write more data than this!)
	- when it means Transfer Length it is the
Expected Data Transfer Length (READ/WRITE), and I say
``expected'' less any End Of Media or similar errors pop up,
(i.e. number of blocks from CDB * block_size = this value).

I.e. the _actual_ buffer size *is* IRRELEVANT to LLDD and
the Transport/IC -- since it maybe an offset to another yet
bigger buffer and SCSI Core/Appl. Client maybe requesting
part of some data (see SAM-3r6, 5.4.3).

Some transports provide an Overflow and Underflow bits in
the transport protocol to let the Initiator port (LLDD)
know about any residuals -- SCSI Core struct scsi_cmnd supports
only an underflow residual (bytes that were not transferred out
of the number of bytes that were expected to be transferred).

I don't know much about USB Storage, but what do you think
about this: add an unsigned overflow_resid to struct scsi_cmnd,
and set it to an applicable value when a USB storage device
provided more data to be transferred, but the buffer was too small.
(I can see how this will not work, if you need a large enough ptr
to just write the data to...)

-- 
Luben