On Tue, Feb 12 2008 at 21:41 +0200, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > 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 > > Am I right in assuming that I only need to audited the drivers that have .unchecked_isa_dma set? I will redo this audit again, and report back. Boaz - 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
