The patch we suggested where we simply changed BLK_MAX_CDB and MAX_COMMAND_SIZE from 16 to 32 was meant to be a "stick in the sand". It's the simplest description of the functionality we're looking for. Other approaches that accomplish the same thing would be fine.
I don't know if the reason that "sd" went with the mempool for 32-byte commands was binary compatibility with modules, concerns about memory usage on small/embedded systems, or both. But given that "sd" uses the mempool, it's reasonable to assume that greater than 16 byte pass-through requests might also take this approach. A potential advantage of using a mempool or other dynamic allocation for the pass-through CDB is that it could be implemented to allow arbitrary CDB sizes, which would be more general than just increasing the fixed limit from 16 to 32. >> We did the mempool because we did not want to penalize everybody else by >> always allocating 32-byte CDBs. Type 2 is a really rare corner case. All of the SCSI drives we're seeing now come from the vendor formatted with PI type 2. Linux automatically detects the format and uses PI, so it's no longer a corner case -- it's now the normal case. If you accept that dynamically allocated CDB's have become the rule rather than the exception, then it makes sense that the fixed size __cmd buffer in struct request should eventually be phased out. Two places in the kernel accept SG_IO (pass-through) requests. One is the "sg" driver; the other (and the one we actually care about more) is scsi_cmd_ioctl in block/scsi_ioctl.c, which handles pass-through requests sent directly to an "sd" device. What we are looking for is simply to be able to send 32-byte pass-through commands. These commands do not have the prot_op and prot_type fields of struct scsi_cmnd set, so from the perspective of the Linux SCSI subsystem and the adapter firmware, they are -not- PI I/O's. But if a pass-through command sent to the device happened to be a 32-byte read with RDPROTECT=3, for example, then the drive will return the PI interleaved with the data -- it's this raw pass-through functionality that we need. Conveniently, increasing the CDB size doesn't break binary compatibility with the existing sg_io_hdr_t. One could develop a more general pass-through command that gave the user access to the prot_op and prot_type fields and that provided a DIX style side-buffer to hold de-interleaved PI data. That would be a nice extension, but it's not something we currently need. Scott Guthridge IBM Almaden Research Center -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
