Skip to contentSkip to conversation

Reimplement the SG_FLAG_LUN_INHIBIT flag in sg's SG_IOCTL.

PATCH In review David Caldwell 2 participants 4 messages Dec 16, 2005 – Dec 19, 2005

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Reimplement the SG_FLAG_LUN_INHIBIT flag in sg's SG_IOCTL.

scsi.c will normally overwrite the second byte of the command with the appropriate LUN info if the device is a SCSI 2 device. I have a device that uses the second byte of the cdb for something other than the LUN (yes, it is a stupid broken device). This flag allows such broken devices work.

---

 drivers/scsi/scsi.c         |    3 ++-
 drivers/scsi/sg.c           |    1 +
 include/scsi/scsi_request.h |    1 +
 include/scsi/sg.h           |    2 +-
 4 files changed, 5 insertions(+), 2 deletions(-)

a1c5985460e92ae1262b411b26b095a0af8aa7b7

drivers/scsi/scsi.c +2 -1
index 180676d..55506ff 100644
@@ -567,7 +567,8 @@ int scsi_dispatch_cmd(struct scsi_cmnd *
 	/* 
 	 * If SCSI-2 or lower, store the LUN value in cmnd.
 	 */
-	if (cmd->device->scsi_level <= SCSI_2) {
+	if (cmd->device->scsi_level <= SCSI_2 &&
+	    !(cmd->sc_request && cmd->sc_request->sr_dont_stomp_lun)) {
 		cmd->cmnd[1] = (cmd->cmnd[1] & 0x1f) |
 			       (cmd->device->lun << 5 & 0xe0);
 	}
drivers/scsi/sg.c +1 -0
index b55c2a8..2441630 100644
@@ -755,6 +755,7 @@ sg_common_write(Sg_fd * sfp, Sg_request 
 		SRpnt->sr_data_direction = DMA_NONE;
 		break;
 	}
+	SRpnt->sr_dont_stomp_lun = !!(hp->flags & SG_FLAG_LUN_INHIBIT);
 	SRpnt->upper_private_data = srp;
 	srp->data.k_use_sg = 0;
 	srp->data.sglist_len = 0;
include/scsi/scsi_request.h +1 -0
index 98d69fd..f8257f9 100644
@@ -39,6 +39,7 @@ struct scsi_request {
 	int sr_timeout_per_command;
 	unsigned short sr_use_sg;	/* Number of pieces of scatter-gather */
 	unsigned short sr_sglist_len;	/* size of malloc'd scatter-gather list */
+	int sr_dont_stomp_lun;	/* Set to 1 to leave sr_cmnd[1] unmolested */
 	unsigned sr_underflow;	/* Return error if less than
 				   this amount is transferred */
  	void *upper_private_data;	/* reserved for owner (usually upper
include/scsi/sg.h +1 -1
index 0a487fe..6151e9c 100644
@@ -139,7 +139,7 @@ typedef struct sg_io_hdr
 
 /* following flag values can be "or"-ed together */
 #define SG_FLAG_DIRECT_IO 1     /* default is indirect IO */
-#define SG_FLAG_UNUSED_LUN_INHIBIT 2   /* default is overwrite lun in SCSI */
+#define SG_FLAG_LUN_INHIBIT 2   /* default is overwrite lun in SCSI */
 				/* command block (when <= SCSI_2) */
 #define SG_FLAG_MMAP_IO 4       /* request memory mapped IO */
 #define SG_FLAG_NO_DXFER 0x10000 /* no transfer of kernel buffers to/from */
Signature · 1 line
0.99.9l
#1 lore raw
Quoted 5 lines · David Caldwell

scsi.c will normally overwrite the second byte of the command with the appropriate LUN info if the device is a SCSI 2 device. I have a device that uses the second byte of the cdb for something other than the LUN (yes, it is a stupid broken device). This flag allows such broken devices work.

scsi_request is hopefully not going to survive 2.6.16 so at this point this patch is not interesting in this form.

#2 lore raw
Quoted 9 lines · On 12/17/05 12:28 PM +0000 Christoph Hellwig wrote:
Quoted 5 lines · David Caldwell

scsi.c will normally overwrite the second byte of the command with the appropriate LUN info if the device is a SCSI 2 device. I have a device that uses the second byte of the cdb for something other than the LUN (yes, it is a stupid broken device). This flag allows such broken devices work.

scsi_request is hopefully not going to survive 2.6.16 so at this point this patch is not interesting in this form.

Have you started this work yet? I can re-implement the patch in the latest code base if you can point me to it.

If not, then why not take the patch? It's only 3 lines of code! Then it becomes just another [small] part of the restructuring work that is planned. In the worst case it can be removed at that point if it's really annoying to think about.

-David

#3 lore raw
Quoted 5 lines · David Caldwell
Quoted 2 lines

scsi_request is hopefully not going to survive 2.6.16 so at this point this patch is not interesting in this form.

Have you started this work yet? I can re-implement the patch in the latest code base if you can point me to it.

In James' scsi-misc tree the work is almost done. All drivers but osst and gdth are not using scsi_request anymore. Any implementation that support the block/scsi_ioctl.c and drivers/scsi/sg.c SG_IO implementations in that tree should be fine with when scsi_request is finally gone.