allow a transport to pre-initialize starget_data

Add a new void *transport_data argument to scsi_scan_target so that a transport-class can fill in known information before actually scanning the target. This is needed by the upcoming SAS transport class patch.

Add a new void *transport_data argument to scsi_scan_target so that a transport-class can fill in known information before actually scanning the target. This is needed by the upcoming SAS transport class patch.

Signed-off-by Christoph Hellwig <[email protected]>

Index: scsi-misc-2.6/drivers/scsi/scsi_scan.c
===================================================================

drivers/scsi/scsi_scan.c +19 -8

@@ -329,7 +329,8 @@
 }
 
 static struct scsi_target *scsi_alloc_target(struct device *parent,
-					     int channel, uint id)
+					     int channel, uint id,
+					     void *transport_data)
 {
 	struct Scsi_Host *shost = dev_to_shost(parent);
 	struct device *dev = NULL;

@@ -344,6 +345,12 @@
 		return NULL;
 	}
 	memset(starget, 0, size);
+
+	if (transport_data) {
+		memcpy((char *)starget->starget_data, transport_data,
+				shost->transportt->target_size);
+	}
+
 	dev = &starget->dev;
 	device_initialize(dev);
 	starget->reap_ref = 1;

@@ -1244,8 +1251,9 @@
 	struct scsi_device *sdev;
 	struct device *parent = &shost->shost_gendev;
 	int res;
-	struct scsi_target *starget = scsi_alloc_target(parent, channel, id);
+	struct scsi_target *starget;
 
+	starget = scsi_alloc_target(parent, channel, id, NULL);
 	if (!starget)
 		return ERR_PTR(-ENOMEM);
 

@@ -1301,7 +1309,8 @@
  *     sequential scan of LUNs on the target id.
  **/
 void scsi_scan_target(struct device *parent, unsigned int channel,
-		      unsigned int id, unsigned int lun, int rescan)
+		      unsigned int id, unsigned int lun, int rescan,
+		      void *transport_data)
 {
 	struct Scsi_Host *shost = dev_to_shost(parent);
 	int bflags = 0;

@@ -1316,8 +1325,7 @@
 		return;
 
 
-	starget = scsi_alloc_target(parent, channel, id);
-
+	starget = scsi_alloc_target(parent, channel, id, transport_data);
 	if (!starget)
 		return;
 

@@ -1388,10 +1396,12 @@
 				order_id = shost->max_id - id - 1;
 			else
 				order_id = id;
-			scsi_scan_target(&shost->shost_gendev, channel, order_id, lun, rescan);
+			scsi_scan_target(&shost->shost_gendev, channel,
+					 order_id, lun, rescan, NULL);
 		}
 	else
-		scsi_scan_target(&shost->shost_gendev, channel, id, lun, rescan);
+		scsi_scan_target(&shost->shost_gendev, channel,
+				 id, lun, rescan, NULL);
 }
 
 int scsi_scan_host_selected(struct Scsi_Host *shost, unsigned int channel,

@@ -1492,7 +1502,8 @@
 	struct scsi_device *sdev;
 	struct scsi_target *starget;
 
-	starget = scsi_alloc_target(&shost->shost_gendev, 0, shost->this_id);
+	starget = scsi_alloc_target(&shost->shost_gendev, 0,
+				    shost->this_id, NULL);
 	if (!starget)
 		return NULL;
 

Index: scsi-misc-2.6/drivers/scsi/scsi_transport_fc.c
===================================================================

drivers/scsi/scsi_transport_fc.c +1 -1

@@ -1653,7 +1653,7 @@
 	struct fc_rport *rport = (struct fc_rport *)data;
 
 	scsi_scan_target(&rport->dev, rport->channel, rport->scsi_target_id,
-			SCAN_WILD_CARD, 1);
+			SCAN_WILD_CARD, 1, NULL);
 }
 
 

Index: scsi-misc-2.6/include/scsi/scsi_device.h
===================================================================

include/scsi/scsi_device.h +2 -2

@@ -238,7 +238,8 @@
 extern void scsi_target_quiesce(struct scsi_target *);
 extern void scsi_target_resume(struct scsi_target *);
 extern void scsi_scan_target(struct device *parent, unsigned int channel,
-			     unsigned int id, unsigned int lun, int rescan);
+			     unsigned int id, unsigned int lun, int rescan,
+			     void *transport_data);
 extern void scsi_target_reap(struct scsi_target *);
 extern void scsi_target_block(struct device *);
 extern void scsi_target_unblock(struct device *);
-

To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

While you're at it, rip out the extremely broken "channel" and "id", and leave only the opaque token.

Quoted 2 lines · Luben Tuikov

While you're at it, rip out the extremely broken "channel" and "id", and leave only the opaque token.

Unfortunately, I just found an actual use for channel (exposing underlying physical discs of raid devices) and, unfortunately, we're still not yet at the point where we can use an opaque token for ID, but if someone wants to look into what it would take to convert the rest of SCSI ...

Quoted 6 lines · Luben Tuikov

Quoted 3 lines · Christoph Hellwig

Add a new void *transport_data argument to scsi_scan_target so that a transport-class can fill in known information before actually scanning the target. This is needed by the upcoming SAS transport class patch.

Quoted 4 lines

Hmm, yes, this has been due for 5 years now.

While you're at it, rip out the extremely broken "channel" and "id", and leave only the opaque token.

Well, it's not a token but pre-initialized data. The problem with ripping out channel and id is that userland would break all over, else we'd have done it already.

Hmm, you've
"found an actual use for channel (exposing underlying physical discs
of raid devices)".

I'm completely befuddled James.

What if we didn't have "channel" (SPI leftover) in the first place? Or, if an LU is implemented as a RAID device, how do you find out its individual disks?

Is there a spec or standard that you're following in doing this?

Quoted 4 lines · Luben Tuikov

Hmm, you've
"found an actual use for channel (exposing underlying physical discs
of raid devices)".

Quoted 1 line

I'm completely befuddled James.

For RAID cards in the SCSI subsystem that export RAID devices as SCSI devices, there's a need of a standard way to get at the underlying devices (for DV, parameter setting or configuration). The idea is to expose these devices on a non zero channel.

Quoted 3 lines

What if we didn't have "channel" (SPI leftover) in the first place? Or, if an LU is implemented as a RAID device, how do you find out its individual disks?

It's not a SPI leftover. It's used by HBA's that have two channels that genuinely share resources. Although most modern SCSI cards simply have two chips (and hence two separate HBAs) per channel, there are a few, of which the qlogic fc card is one, that still have this one chip per two channels model.

Quoted 1 line

Is there a spec or standard that you're following in doing this?

It's an OS abstraction, so no.

Isn't DV an SPI paradigm?

If the whole point of the LLDD+controller is to _give_ you this, "an LU which is actually RAID", abstraction, why does SCSI Core need to get to the underlying devices?

What will SCSI Core do with the RAID members? Why is SCSI Core concerned with this information? What kind of parameters will it have to set, without the RAID device server knowing about it (which is implemented on the chip if HW RAID)?

Quoted 5 lines

It's not a SPI leftover. It's used by HBA's that have two channels that genuinely share resources. Although most modern SCSI cards simply have two chips (and hence two separate HBAs) per channel, there are a few, of which the qlogic fc card is one, that still have this one chip per two channels model.

Ah, I see.

Please help me understand this:

You say that "channel" is not an SPI leftover but it is used by SCSI Core because

"HBA's that have two channels that genuinely share resources".

Why is SCSI Core concerned with how HBAs are _built_? Isn't this the LLDD's job?

Is "channel" in SCSI Core used to _address_ SCSI devices? How many of those "channel" will we need?

Quoted 4 lines

What will SCSI Core do with the RAID members? Why is SCSI Core concerned with this information? What kind of parameters will it have to set, without the RAID device server knowing about it (which is implemented on the chip if HW RAID)?

Nothing except expose them ... that's the idea. The parameters are set from user level after that. This elimiates need for the pass through ioctl that all of these drivers have.

Quoted 3 lines · Christoph Hellwig

Add a new void *transport_data argument to scsi_scan_target so that a transport-class can fill in known information before actually scanning the target. This is needed by the upcoming SAS transport class patch.

Hmm, yes, this has been due for 5 years now.

While you're at it, rip out the extremely broken "channel" and "id", and leave only the opaque token.