On Sun, 2008-02-10 at 21:05 +0200, Boaz Harrosh wrote: > - struct scsi_cmnd had a 16 bytes command buffer of its own. > This is an unnecessary duplication and copy of request's > cmd. It is probably left overs from the time that scsi_cmnd > could function without a request attached. So clean that up. > > - Once above is done, few places, apart from scsi-ml, needed > adjustments due to changing the data type of scsi_cmnd->cmnd. > > - Lots of drivers still use MAX_COMMAND_SIZE. So I have left > that #define but equate it to BLK_MAX_CDB. The way I see it > and is reflected in the patch below is. > MAX_COMMAND_SIZE - means: The longest fixed-length (*) SCSI CDB > as per the SCSI standard and is not related > to the implementation. > BLK_MAX_CDB. - The allocated space at the request level > > (*)fixed-length here means commands that their size can be determined > by their opcode and the CDB does not carry a length specifier, like > the VARIABLE_LENGTH_CMD(0x7f) command. This is actually not exactly > true and the SCSI standard also defines extended commands and > vendor specific commands that can be bigger than 16 bytes. The kernel > will support these using the same infrastructure used for VARLEN CDB's. > So in effect MAX_COMMAND_SIZE means the maximum size command > scsi-ml supports without specifying a cmd_len by ULD's When we do this, what happens to the minority of drivers that need the command in DMAable memory ... or have you audited them all and we can now dump the DMA pool allocation for SCSI commands? James - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
