On 12-12-19 05:34 AM, Scott Guthridge wrote:
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.
Scott,
You overlooked the bsg driver which will allow you to issue
32 byte cdbs (and larger). It is probably about time I
submitted a patch to allow the sg driver to handle cdbs
larger than 16 bytes.
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.
If you follow the code for sg_write_same in sg3_utils (version 1.34)
there is a case in which the 32 byte cdb is issued. To work in Linux
it must take the path for bsg through my lower level library. That
will end up populating an instance of struct sg_io_v4 and sending
it to a bsg device node via the SG_IO ioctl.
You might also look at the examples/bsg_queue_tst.c file in the
sg3_utils tarball.
Doug Gilbert
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
