scsi_dh: Make scsi device handler modules automatically inserted

Hello,

Currently, SCSI targets doesn't have modalias support. It wasn't an issue until SCSI device handler came along.

We want the SCSI device handler modules to be insmodded automatically when the specific SCSI targets are probed and found.

This set of patches adds the modalias support for SCSI targets and also makes the relevant changes to SCSI device handler modules to make use of it.

Applies cleanly on 2.6.30-rc3 and is tested on the same.

Please review and consider this for inclusion.

Originally sent on March 17 2009 (http://marc.info/?l=linux-scsi&m=123734001009654&w=2).

Resending after testing on 2.6.30-rc3 and with an ack from Hannes.

Quoted 14 lines · Chandra Seetharaman

Hello,

Currently, SCSI targets doesn't have modalias support. It wasn't an issue until SCSI device handler came along.

We want the SCSI device handler modules to be insmodded automatically when the specific SCSI targets are probed and found.

This set of patches adds the modalias support for SCSI targets and also makes the relevant changes to SCSI device handler modules to make use of it.

Applies cleanly on 2.6.30-rc3 and is tested on the same.

Quoted 5 lines

Please review and consider this for inclusion.

Originally sent on March 17 2009 (http://marc.info/?l=linux-scsi&m=123734001009654&w=2).

Resending after testing on 2.6.30-rc3 and with an ack from Hannes.

Was there ever any followup to this?

Quoted 14 lines · Chandra Seetharaman

Hello,

Currently, SCSI targets doesn't have modalias support. It wasn't an issue until SCSI device handler came along.

We want the SCSI device handler modules to be insmodded automatically when the specific SCSI targets are probed and found.

This set of patches adds the modalias support for SCSI targets and also makes the relevant changes to SCSI device handler modules to make use of it.

Applies cleanly on 2.6.30-rc3 and is tested on the same.

Quoted 5 lines

Please review and consider this for inclusion.

Originally sent on March 17 2009 (http://marc.info/?l=linux-scsi&m=123734001009654&w=2).

Resending after testing on 2.6.30-rc3 and with an ack from Hannes.

Was there ever any followup to this?

Quoted 19 lines · Peter Jones

Quoted 18 lines · Chandra Seetharaman

Hello,

Currently, SCSI targets doesn't have modalias support. It wasn't an issue until SCSI device handler came along.

We want the SCSI device handler modules to be insmodded automatically when the specific SCSI targets are probed and found.

This set of patches adds the modalias support for SCSI targets and also makes the relevant changes to SCSI device handler modules to make use of it.

Applies cleanly on 2.6.30-rc3 and is tested on the same.

Please review and consider this for inclusion.

Originally sent on March 17 2009 (http://marc.info/?l=linux-scsi&m=123734001009654&w=2).

Quoted 2 lines

Quoted 1 line

Resending after testing on 2.6.30-rc3 and with an ack from Hannes.

Was there ever any followup to this?

OK, since I've forgotten where we are, let me summarise what I think the situation is (correct me if I misstate any of the facts):

This code adds no functional value to the kernel because dm already autoloads the correct handlers based on the inquiry strings

The only value it adds is that by overloading the module table with the inquiry strings, mkinitrd pulls in the correct dm handlers for the state the system was in.

the unaddressed problems are:

The kernel now tries to load the dm handler for the device dynamically whether or not the user is actually deploying multi-path (previously dm does this and if it's not loaded, that doesn't happen). It's entirely unclear whether this would interfere with proprietary multipath handlers or even cause problems in single path systems which were designed that way.

Quoted 19 lines · James Bottomley

Quoted 18 lines · Peter Jones

Quoted 17 lines · Chandra Seetharaman

Hello,

Currently, SCSI targets doesn't have modalias support. It wasn't an issue until SCSI device handler came along.

We want the SCSI device handler modules to be insmodded automatically when the specific SCSI targets are probed and found.

This set of patches adds the modalias support for SCSI targets and also makes the relevant changes to SCSI device handler modules to make use of it.

Applies cleanly on 2.6.30-rc3 and is tested on the same.

Please review and consider this for inclusion.

Originally sent on March 17 2009 (http://marc.info/?l=linux-scsi&m=123734001009654&w=2).

Quoted 7 lines

Quoted 2 lines

Quoted 1 line

Resending after testing on 2.6.30-rc3 and with an ack from Hannes.

Was there ever any followup to this?

OK, since I've forgotten where we are, let me summarise what I think the situation is (correct me if I misstate any of the facts):

This code adds no functional value to the kernel because dm already autoloads the correct handlers based on the inquiry strings

I don't agree here. It adds functional value to the entire system by making the loading of device drivers use the same method no matter which kernel subsystem the driver is part of. This is a very tangible benefit in terms of maintainability.

Quoted 3 lines

The only value it adds is that by overloading the module table with the inquiry strings, mkinitrd pulls in the correct dm handlers for the state the system was in.

You keep on saying this, and to me it seems very strange. The patch does no "overloading" of vendor strings -- it uses them just like the PCI vendor/device ID or USB idVendor/idDevice. Fundamentally they are the same thing: an identifier to tell us what device we're looking at. There's no overloading here, it's just hooking them up to the kernel's generalized mechanism for loading modules based on this kind of data.

Quoted 8 lines

the unaddressed problems are:

The kernel now tries to load the dm handler for the device dynamically whether or not the user is actually deploying multi-path (previously dm does this and if it's not loaded, that doesn't happen). It's entirely unclear whether this would interfere with proprietary multipath handlers or even cause problems in single path systems which were designed that way.

I just don't see how this is a real concern -- the whole point of the drivers which we're autoloading here is to work with specific hardware that's designed to work in this fashion. What's more, if that hardware is being used for single-path, and the driver is loaded and it decides to reconfigure to prefer a path that's not plugged in, surely that's a bug in the device handler driver, and should be fixed there, rather than blocking the auto-loading of such drivers?

James, I think Chandra and I have responded to most if not all of your points, and would appreciate your thoughts on what we've said.

Quoted 2 lines · Peter Jones

James, I think Chandra and I have responded to most if not all of your points, and would appreciate your thoughts on what we've said.

Well, you didn't respond to the important one:

You're seeking to change the binding of these helpers from manual to automatic. This would mean that the modules are loaded in the single controller case, for which they may not be wanted and also when some multi path tool other than dm-mp is managing the device, in which case they may actively interfere with operations. Your basic contention is that you "don't see any concern here".

This is by design (of SCSI DH). We do want the device to be attached to its handler _irrespective_ of whether multipath comes along or not.

BTW, there is _no_ infrastructure in multipath for handlers. They were removed from multipath when scsi dh came along. So, no worries about proprietary multipath handlers. Also, multipath _can_ attach a device to a different (SCSI) device handler if it finds that the one that is already attached is not the right one.

When I ask what testing you've done for either of these, the studied silence eloquently illustrates "none". A policy change like this can't be made without being incredibly sure we're not going to screw up existing installations.

The second point I made speaks to the technical ugliness of this: what you're basically doing is open coding multiple binding for a device handler specific case. If you can persuade me the policy above is correct, then technically all this should be done correctly via multiple binding in the generic device core ... before this interface nastiness you're constructing propagates outwards and becomes part of the user ABI.

Quoted 6 lines · James Bottomley

Quoted 2 lines · Peter Jones

James, I think Chandra and I have responded to most if not all of your points, and would appreciate your thoughts on what we've said.

Well, you didn't respond to the important one:

Quoted 6 lines

You're seeking to change the binding of these helpers from manual to automatic. This would mean that the modules are loaded in the single controller case, for which they may not be wanted and also when some multi path tool other than dm-mp is managing the device, in which case they may actively interfere with operations. Your basic contention is that you "don't see any concern here".

I think Chandra addressed this in his reply to your previous email:

[From him]

Quoted 8 lines

This is by design (of SCSI DH). We do want the device to be attached to its handler _irrespective_ of whether multipath comes along or not.

BTW, there is _no_ infrastructure in multipath for handlers. They were removed from multipath when scsi dh came along. So, no worries about proprietary multipath handlers. Also, multipath _can_ attach a device to a different (SCSI) device handler if it finds that the one that is already attached is not the right one.

[From you again]

Quoted 4 lines

When I ask what testing you've done for either of these, the studied silence eloquently illustrates "none". A policy change like this can't be made without being incredibly sure we're not going to screw up existing installations.

I'll let Chandra address this, as it is my understanding that he has hardware and has tested this code with it.

Quoted 7 lines

The second point I made speaks to the technical ugliness of this: what you're basically doing is open coding multiple binding for a device handler specific case. If you can persuade me the policy above is correct, then technically all this should be done correctly via multiple binding in the generic device core ... before this interface nastiness you're constructing propagates outwards and becomes part of the user ABI.

I'm willing to re-implement the functionality with a different mechanism if it has your blessing, if you can be specific about what it is you think would be better. Obviously I'll hold off on that until we've come to some agreement about the other aspects.

Quoted 7 lines · Peter Jones

Quoted 6 lines · James Bottomley

Quoted 2 lines · Peter Jones

James, I think Chandra and I have responded to most if not all of your points, and would appreciate your thoughts on what we've said.

Well, you didn't respond to the important one:

Quoted 8 lines

Quoted 6 lines

You're seeking to change the binding of these helpers from manual to automatic. This would mean that the modules are loaded in the single controller case, for which they may not be wanted and also when some multi path tool other than dm-mp is managing the device, in which case they may actively interfere with operations. Your basic contention is that you "don't see any concern here".

I think Chandra addressed this in his reply to your previous email:

I don't think so:

Quoted 9 lines

[From him]

Quoted 8 lines

This is by design (of SCSI DH). We do want the device to be attached to its handler _irrespective_ of whether multipath comes along or not.

BTW, there is _no_ infrastructure in multipath for handlers. They were removed from multipath when scsi dh came along. So, no worries about proprietary multipath handlers. Also, multipath _can_ attach a device to a different (SCSI) device handler if it finds that the one that is already attached is not the right one.

I want to know what happens when some multipath system other than dm-mp tries to use a system with a device handler attached ... I don't see how that addresses the issue at all. The device handlers, when they're attached can alter sense and return code processing .. this has the potential to interfere with how the other multipath code is expecting things to happen

If we have to get really concrete: what happens with something like powerpath and scsi_dh_emc attached?

Quoted 17 lines

[From you again]

Quoted 4 lines

When I ask what testing you've done for either of these, the studied silence eloquently illustrates "none". A policy change like this can't be made without being incredibly sure we're not going to screw up existing installations.

I'll let Chandra address this, as it is my understanding that he has hardware and has tested this code with it.

Quoted 7 lines

The second point I made speaks to the technical ugliness of this: what you're basically doing is open coding multiple binding for a device handler specific case. If you can persuade me the policy above is correct, then technically all this should be done correctly via multiple binding in the generic device core ... before this interface nastiness you're constructing propagates outwards and becomes part of the user ABI.

Quoted 4 lines

I'm willing to re-implement the functionality with a different mechanism if it has your blessing, if you can be specific about what it is you think would be better. Obviously I'll hold off on that until we've come to some agreement about the other aspects.

Well, the two things aren't so dependent: this dh_state attribute that hannes just NAK'd is precisely a binding attribute for your hand rolled

multiple driver attachment, so actually getting generic device multiple binding sorted out would help out regardless of what the final attachment policy decision is.

James

Quoted 3 lines · Peter Jones

Quoted 2 lines · James Bottomley

Quoted 1 line · Peter Jones

James, I think Chandra and I have responded to most if not all of

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

and would appreciate your thoughts on what we've said.

Well, you didn't respond to the important one:

You're seeking to change the binding of these helpers from manual

Quoted 1 line

Quoted 1 line

automatic. This would mean that the modules are loaded in the

Quoted 1 line

Quoted 1 line

controller case, for which they may not be wanted and also when

Quoted 1 line

Quoted 1 line

multi path tool other than dm-mp is managing the device, in which

Quoted 1 line

Quoted 1 line

they may actively interfere with operations. Your basic

Quoted 3 lines

Quoted 1 line

that you "don't see any concern here".

I think Chandra addressed this in his reply to your previous email:

I don't think so:

Quoted 2 lines

[From him]

Quoted 1 line

This is by design (of SCSI DH). We do want the device to be

Quoted 1 line

Quoted 1 line

its handler _irrespective_ of whether multipath comes along or

Quoted 2 lines

Quoted 2 lines

BTW, there is _no_ infrastructure in multipath for handlers. They

Quoted 1 line

Quoted 1 line

removed from multipath when scsi dh came along. So, no worries

Quoted 1 line

Quoted 1 line

proprietary multipath handlers. Also, multipath _can_ attach a

Quoted 2 lines

Quoted 2 lines

a different (SCSI) device handler if it finds that the one that is already attached is not the right one.

I want to know what happens when some multipath system other than

tries to use a system with a device handler attached ... I don't see

that addresses the issue at all. The device handlers, when they're attached can alter sense and return code processing .. this has the potential to interfere with how the other multipath code is expecting things to happen

If we have to get really concrete: what happens with something like powerpath and scsi_dh_emc attached?

Quoted 2 lines

[From you again]

Quoted 1 line

When I ask what testing you've done for either of these, the

Quoted 2 lines

Quoted 2 lines

silence eloquently illustrates "none". A policy change like this can't be made without being incredibly sure we're not going to

Quoted 6 lines

Quoted 1 line

up existing installations.

I'll let Chandra address this, as it is my understanding that he has hardware and has tested this code with it.

Quoted 1 line

The second point I made speaks to the technical ugliness of this:

Quoted 1 line

Quoted 1 line

you're basically doing is open coding multiple binding for a

Quoted 2 lines

Quoted 2 lines

handler specific case. If you can persuade me the policy above is correct, then technically all this should be done correctly via

Quoted 1 line

Quoted 1 line

binding in the generic device core ... before this interface

Quoted 1 line

Quoted 1 line

you're constructing propagates outwards and becomes part of the

Quoted 3 lines

Quoted 1 line

ABI.

I'm willing to re-implement the functionality with a different

Quoted 1 line

if it has your blessing, if you can be specific about what it is you

Quoted 1 line

would be better. Obviously I'll hold off on that until we've come

Quoted 1 line

agreement about the other aspects.

Well, the two things aren't so dependent: this dh_state attribute that hannes just NAK'd is precisely a binding attribute for your hand

multiple driver attachment, so actually getting generic device

binding sorted out would help out regardless of what the final attachment policy decision is.

James

Hi Chandra.

I can speak for EMC PowerPath in that it is affect by DM if both
are trying to control the same device. Another large multipathing solution that may be affected would be Symantec's DMP.

Regards,
Wayne.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Chandra Seetharaman
Sent: Tuesday, July 07, 2009 3:37 PM
To: James Bottomley
Cc: Peter Jones; [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH 0/3] scsi_dh: Make scsi device handler modulesautomatically inserted

Quoted 4 lines · James Bottomley

Quoted 3 lines · Peter Jones

Quoted 2 lines · James Bottomley

Quoted 1 line · Peter Jones

James, I think Chandra and I have responded to most if not all of

your points,

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

and would appreciate your thoughts on what we've said.

Well, you didn't respond to the important one:

You're seeking to change the binding of these helpers from manual

to

Quoted 1 line

Quoted 1 line

Quoted 1 line

automatic. This would mean that the modules are loaded in the

single

Quoted 1 line

Quoted 1 line

Quoted 1 line

controller case, for which they may not be wanted and also when

some

Quoted 1 line

Quoted 1 line

Quoted 1 line

multi path tool other than dm-mp is managing the device, in which

case

Quoted 1 line

Quoted 1 line

Quoted 1 line

they may actively interfere with operations. Your basic

contention is

Quoted 8 lines

Quoted 3 lines

Quoted 1 line

that you "don't see any concern here".

I think Chandra addressed this in his reply to your previous email:

I don't think so:

Quoted 2 lines

[From him]

Quoted 1 line

This is by design (of SCSI DH). We do want the device to be

attached to

Quoted 1 line

Quoted 1 line

Quoted 1 line

its handler _irrespective_ of whether multipath comes along or

not.

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

BTW, there is _no_ infrastructure in multipath for handlers. They

were

Quoted 1 line

Quoted 1 line

Quoted 1 line

removed from multipath when scsi dh came along. So, no worries

about

Quoted 1 line

Quoted 1 line

Quoted 1 line

proprietary multipath handlers. Also, multipath _can_ attach a

device to

Quoted 4 lines

Quoted 2 lines

Quoted 2 lines

a different (SCSI) device handler if it finds that the one that is already attached is not the right one.

I want to know what happens when some multipath system other than

dm-mp

Quoted 1 line

tries to use a system with a device handler attached ... I don't see

how

Quoted 4 lines

that addresses the issue at all. The device handlers, when they're attached can alter sense and return code processing .. this has the potential to interfere with how the other multipath code is expecting things to happen

When I responded to your earlier email I thought you meant the interaction between dm-mp and the hardware handler ( and not other out-of-tree multipath solutions). My answer was in that context alone.

Yes, your conclusion is correct. There are few functionalities in the hardware handler interface that might affect the above layers (block and above). One is the prep_fn() function, second is the check_sense() function, and third is the activate() function.

Since scsi_dh is designed for dm-mp :).

I do not know of all the out-of-tree multipath solutions and how they behave and at what layer they interact. In effect, I haven't tested hardware handler with other multipath solutions.

Quoted 4 lines

If we have to get really concrete: what happens with something like powerpath and scsi_dh_emc attached?

They _might_ be affected as mentioned above.

Quoted 2 lines

Quoted 2 lines

[From you again]

Quoted 1 line

When I ask what testing you've done for either of these, the

studied

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

silence eloquently illustrates "none". A policy change like this can't be made without being incredibly sure we're not going to

screw

Quoted 6 lines

Quoted 6 lines

Quoted 1 line

up existing installations.

I'll let Chandra address this, as it is my understanding that he has hardware and has tested this code with it.

Quoted 1 line

The second point I made speaks to the technical ugliness of this:

what

Quoted 1 line

Quoted 1 line

Quoted 1 line

you're basically doing is open coding multiple binding for a

device

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

handler specific case. If you can persuade me the policy above is correct, then technically all this should be done correctly via

multiple

Quoted 1 line

Quoted 1 line

Quoted 1 line

binding in the generic device core ... before this interface

nastiness

Quoted 1 line

Quoted 1 line

Quoted 1 line

you're constructing propagates outwards and becomes part of the

user

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

ABI.

I'm willing to re-implement the functionality with a different

mechanism

Quoted 1 line

Quoted 1 line

if it has your blessing, if you can be specific about what it is you

think

Quoted 1 line

Quoted 1 line

would be better. Obviously I'll hold off on that until we've come

to some

Quoted 4 lines

Quoted 1 line

agreement about the other aspects.

Well, the two things aren't so dependent: this dh_state attribute that hannes just NAK'd is precisely a binding attribute for your hand

rolled

Just to clarify:

dh_state attribute is not added new, it was originally added by Hannes.

I just fixed a problem to make it work as it is intended, and sent an explanation (about my fix) for Hannes to reconsider is NAK.

Quoted 1 line

multiple driver attachment, so actually getting generic device

multiple

Quoted 6 lines

binding sorted out would help out regardless of what the final attachment policy decision is.

James

--
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

I do not know of all the out-of-tree multipath solutions and how they behave and at what layer they interact. In effect, I haven't tested hardware handler with other multipath solutions.

Quoted 3 lines · Chandra Seetharaman

I do not know of all the out-of-tree multipath solutions and how they behave and at what layer they interact. In effect, I haven't tested hardware handler with other multipath solutions.

It doesn't matter anyway. We've never cared about these out of tree problems and they'll have to find a way by themselves to deal with any changes we do to offer better multipath support upstream.

--
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

Quoted 3 lines · Chandra Seetharaman

I do not know of all the out-of-tree multipath solutions and how they behave and at what layer they interact. In effect, I haven't tested hardware handler with other multipath solutions.

It doesn't matter anyway. We've never cared about these out of tree problems and they'll have to find a way by themselves to deal with any changes we do to offer better multipath support upstream.

This behavior is conditional on the module parameter scsi_mod.target_modalias_has_vendor, which has its default set by the enabling or disabling of CONFIG_SCSI_TARGET_MODALIAS_WITH_ID .

Quoted 3 lines · Peter Jones

This behavior is conditional on the module parameter scsi_mod.target_modalias_has_vendor, which has its default set by the enabling or disabling of CONFIG_SCSI_TARGET_MODALIAS_WITH_ID .

Sorry, but that's really stupid. If people have the arrays that have device handlers there are two possible cases:

- just a single port configured on the array. In this case the device handlers are useless but also completely unharmful.
- multiple ports configured on the array. In this case we desperately want the device handlers loaded early so that we do the right thing for the inactive ports and avoid the horrible probing delays, not matter if we actually do end up using multipath later or no.

No need to make this configurable. If people really do not want the handler (e.g. becuase the may end up beeing buggy for a new array matching the old idea) they can just blacklist it in the modules configuration.

Quoted 8 lines · Christoph Hellwig

Quoted 3 lines · Chandra Seetharaman

I do not know of all the out-of-tree multipath solutions and how they behave and at what layer they interact. In effect, I haven't tested hardware handler with other multipath solutions.

It doesn't matter anyway. We've never cared about these out of tree problems and they'll have to find a way by themselves to deal with any changes we do to offer better multipath support upstream.

That's definitely how I feel about it, but James apparently disagrees. Anyway, to alleviate some of his concerns, here's a different starting point that maybe we could work from. James, tell me how you feel about this?

From: Peter Jones <[email protected]>
Date: Tue, 7 Jul 2009 15:08:00 -0400
Subject: [PATCH] Add scsi device and vendor IDs to scsi target modaliases.

This patch adds scsi device and vendor IDs to scsi target modaliases, including the corresponding uevents and sysfs modalias file.

This behavior is conditional on the module parameter scsi_mod.target_modalias_has_vendor, which has its default set by the enabling or disabling of CONFIG_SCSI_TARGET_MODALIAS_WITH_ID .

---
 drivers/scsi/Kconfig           |   10 +++++
 drivers/scsi/scsi_sysfs.c      |   72 ++++++++++++++++++++++++++++++++++++++-
 include/linux/string_helpers.h |    2 +
 include/scsi/scsi_device.h     |    1 -
 lib/string_helpers.c           |   32 ++++++++++++++++++
 5 files changed, 114 insertions(+), 3 deletions(-)

drivers/scsi/Kconfig +10 -0

index 9c23122..b18c329 100644
@@ -239,6 +239,16 @@ config SCSI_LOGGING
 	  there should be no noticeable performance impact as long as you have
 	  logging turned off.
 
+config SCSI_TARGET_MODALIAS_WITH_ID
+	bool "Include vendor/device IDs in SCSI target modalias strings"
+	default n
+	depends on SCSI
+	help
+	  The SCSI subsystem can present modalias strings for SCSI target
+	  devices either with or without vendor and device ID data.
+	  This is experimental, and make cause undesirable interactions with
+	  some device management programs.
+
 config SCSI_SCAN_ASYNC
 	bool "Asynchronous SCSI scanning"
 	depends on SCSI

drivers/scsi/scsi_sysfs.c +70 -2

index 91482f2..af4030c 100644
@@ -10,6 +10,7 @@
 #include <linux/init.h>
 #include <linux/blkdev.h>
 #include <linux/device.h>
+#include <linux/string_helpers.h>
 
 #include <scsi/scsi.h>
 #include <scsi/scsi_device.h>

@@ -362,16 +363,80 @@ static int scsi_bus_match(struct device *dev, struct device_driver *gendrv)
 	return (sdp->inq_periph_qual == SCSI_INQ_PQ_CON)? 1: 0;
 }
 
+#ifdef CONFIG_SCSI_TARGET_MODALIAS_WITH_ID
+static unsigned int scsi_target_modalias_has_vendor = 1;
+#else
+static unsigned int scsi_target_modalias_has_vendor = 0;
+#endif
+
+module_param_named(target_modalias_has_vendor, scsi_target_modalias_has_vendor,
+		   uint, S_IRUGO|S_IWUSR);
+MODULE_PARAM_DESC(target_modalias_has_vendor, "control presense of vendor and device ID in scsi target modaliases");
+
+static ssize_t format_scsi_modalias(struct scsi_device *sdev, char *buffer,
+				    ssize_t len)
+{
+	int i = 0;
+
+	if (scsi_target_modalias_has_vendor) {
+		int j;
+		char vendor[9];
+		char *hex_vendor;
+		char model[17];
+		char *hex_model;
+	
+		strncpy(vendor, sdev->vendor, 8);
+		vendor[8] = '\0';
+		for (j = strlen(vendor) - 1; j >= 0; j--) {
+			if (vendor[j] != ' ')
+				break;
+			vendor[j] = '\0';
+		}
+		hex_vendor = string_to_hex(vendor);
+		if (!hex_vendor)
+			return -ENOMEM;
+	
+		strncpy(model, sdev->model, 16);
+		model[8] = '\0';
+		for (j = strlen(model) - 1; j >= 0; j--) {
+			if (model[j] != ' ')
+				break;
+			model[j] = '\0';
+		}
+		hex_model = string_to_hex(model);
+		if (!hex_model) {
+			kfree(hex_vendor);
+			return -ENOMEM;
+		}
+	
+		i = snprintf(buffer, len, "scsi:t-0x%02xv%.16sm%.32s",
+			sdev->type, hex_vendor, hex_model);
+		kfree(hex_vendor);
+		kfree(hex_model);
+	} else {
+		i = snprintf(buffer, len, "scsi:t-0x%02x" sdev->type);
+	}
+
+	return i;
+}
+
 static int scsi_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
 {
 	struct scsi_device *sdev;
+	char buffer[501];
+	int rc;
 
 	if (dev->type != &scsi_dev_type)
 		return 0;
 
 	sdev = to_scsi_device(dev);
 
-	add_uevent_var(env, "MODALIAS=" SCSI_DEVICE_MODALIAS_FMT, sdev->type);
+	buffer[500] = '\0';
+	rc = format_scsi_modalias(sdev, buffer, 500);
+	if (rc < 0)
+		return rc;
+
+	add_uevent_var(env, "MODALIAS=%s", buffer);
 	return 0;
 }
 

@@ -680,8 +745,11 @@ static ssize_t
 sdev_show_modalias(struct device *dev, struct device_attribute *attr, char *buf)
 {
 	struct scsi_device *sdev;
+	ssize_t rc;
+
 	sdev = to_scsi_device(dev);
-	return snprintf (buf, 20, SCSI_DEVICE_MODALIAS_FMT "\n", sdev->type);
+	rc = format_scsi_modalias(sdev, buf, 500);
+	return rc;
 }
 static DEVICE_ATTR(modalias, S_IRUGO, sdev_show_modalias, NULL);
 

include/linux/string_helpers.h +2 -0

index a3eb2f6..46a7594 100644
@@ -13,4 +13,6 @@ enum string_size_units {
 int string_get_size(u64 size, enum string_size_units units,
 		    char *buf, int len);
 
+unsigned char *string_to_hex(const unsigned char *s);
+
 #endif

include/scsi/scsi_device.h +0 -1

index 3f566af..ffa7746 100644
@@ -452,6 +452,5 @@ static inline int scsi_device_protection(struct scsi_device *sdev)
 
 #define MODULE_ALIAS_SCSI_DEVICE(type) \
 	MODULE_ALIAS("scsi:t-" __stringify(type) "*")
-#define SCSI_DEVICE_MODALIAS_FMT "scsi:t-0x%02x"
 
 #endif /* _SCSI_SCSI_DEVICE_H */

lib/string_helpers.c +32 -0

index ab431d4..2ecd500 100644
@@ -66,3 +66,35 @@ int string_get_size(u64 size, const enum string_size_units units,
 	return 0;
 }
 EXPORT_SYMBOL(string_get_size);
+
+/**
+ * string_to_hex - convert a string to a series of hexidecimal values
+ * @s:	The string to operate on
+ *
+ * This function returns a GFP_KERNEL allocated buffer filled with
+ * the hexidecimal representation of the value of each character in @s .
+ * Returns a pointer to the allocated string on success and NULL on error,
+ * and the returned string is zero terminated.
+ *
+ */
+unsigned char *string_to_hex(const unsigned char *s)
+{
+	unsigned char *ret, *ptr;
+	static const unsigned char *hex = "0123456789ABCDEF";
+	int len;
+
+	len = strlen(s);
+
+	ret = ptr = kmalloc(len * 2 + 1, GFP_KERNEL);
+	if (!ret)
+		return NULL;
+
+	for (; *s; s++) {
+		*ptr++ = hex[(*s & 0xf0)>>4];
+		*ptr++ = hex[*s & 0x0f];
+	}
+	*ptr = '\0';
+
+	return ret;
+}
+EXPORT_SYMBOL(string_to_hex);

Signature · 1 line

1.6.2.2

James,

Please let us know which way you want us to proceed ?

We have been pursuing this for more than three months now.

Quoted 3 lines · Chandra Seetharaman

James,

Please let us know which way you want us to proceed ?

Yes, propose a mechanism that keeps manual binding but allows the dm-mp user an exception.

For the actual binding I still think it should be
part of generic driver multiple binding.

Quoted 2 lines

We have been pursuing this for more than three months now.

Well, the concerns I flagged at the outset haven't really changed ... they just seem finally to be better understood.

James

Quoted 7 lines · James Bottomley

Quoted 3 lines · Chandra Seetharaman

James,

Please let us know which way you want us to proceed ?

Yes, propose a mechanism that keeps manual binding but allows the dm-mp user an exception.

James, this is the current behavior. We wanted to make the binding automatic, hence the patches.

Quoted 2 lines

For the actual binding I still think it should be
part of generic driver multiple binding.

I don't quite understand what does this mean. Can you elaborate, please.

Quoted 5 lines · Chandra Seetharaman

Quoted 4 lines · James Bottomley

Quoted 3 lines · Chandra Seetharaman

James,

Please let us know which way you want us to proceed ?

Quoted 4 lines

Quoted 2 lines

Yes, propose a mechanism that keeps manual binding but allows the dm-mp user an exception.

James, this is the current behavior. We wanted to make the binding automatic, hence the patches.

OK, well then no ... I'm not breaking an unknown number of enterprise configurations by forcing a binding where none is wanted or needed. Find a way to do what you want while not breaking anyone else.

Quoted 11 lines · James Bottomley

Quoted 9 lines · Chandra Seetharaman

Quoted 6 lines · James Bottomley

Quoted 3 lines · Chandra Seetharaman

James,

Please let us know which way you want us to proceed ?

Yes, propose a mechanism that keeps manual binding but allows the dm-mp user an exception.

James, this is the current behavior. We wanted to make the binding automatic, hence the patches.

Quoted 3 lines

OK, well then no ... I'm not breaking an unknown number of enterprise configurations by forcing a binding where none is wanted or needed. Find a way to do what you want while not breaking anyone else.

And what about the patch I sent you that makes the uevent modalias change depend on a config option? You've still not commented on it.

Quoted 14 lines · Peter Jones

Quoted 13 lines · James Bottomley

Quoted 9 lines · Chandra Seetharaman

Quoted 6 lines · James Bottomley

Quoted 3 lines · Chandra Seetharaman

James,

Please let us know which way you want us to proceed ?

Yes, propose a mechanism that keeps manual binding but allows the dm-mp user an exception.

James, this is the current behavior. We wanted to make the binding automatic, hence the patches.

OK, well then no ... I'm not breaking an unknown number of enterprise configurations by forcing a binding where none is wanted or needed. Find a way to do what you want while not breaking anyone else.

Quoted 2 lines

And what about the patch I sent you that makes the uevent modalias change depend on a config option? You've still not commented on it.

A config option isn't right, but a runtime one might be if nothing else comes along, I suppose. The uevent modalias still needs to go via multiple binding.

Quoted 2 lines

Was there ever any followup to this?

OK, since I've forgotten where we are, let me summarise what I think the situation is (correct me if I misstate any of the facts):

This code adds no functional value to the kernel because dm already autoloads the correct handlers based on the inquiry strings

The only value it adds is that by overloading the module table with the inquiry strings, mkinitrd pulls in the correct dm handlers for the state the system was in.

the unaddressed problems are:

The kernel now tries to load the dm handler for the device dynamically whether or not the user is actually deploying multi-path (previously dm does this and if it's not loaded, that doesn't happen). It's entirely unclear whether this would interfere with proprietary multipath handlers or even cause problems in single path systems which were designed that way.

So as I see it, the functional benefit to a running kernel is zero and the functional risk exists but is unquantified, so it seems far better simply to solve this issue in mkinitrd.

James

Hi James,

Thanks for getting back on this.

Quoted 8 lines · James Bottomley

Quoted 2 lines

Was there ever any followup to this?

OK, since I've forgotten where we are, let me summarise what I think the situation is (correct me if I misstate any of the facts):

This code adds no functional value to the kernel because dm already autoloads the correct handlers based on the inquiry strings

First point of clarification:

The main purpose of moving the device handlers from the dm-layer to scsi layer was that the time at which dm-layer comes in is too late.

SCSI-DH was added mainly to make sure that scsi layer recognize that these are special devices and has to be handled differently.

(Original problem was that during device probing lot of ios are sent to passive paths which caused boot time delays and tons of errors messages. These increase linearly with the number of luns and the number of passive paths, i.e more redundant the system is, more time it takes to boot and more error messages it spits out).

To paraphrase, if we were willing to wait till dm layer loads appropriate device handler modules, there would be no need for us to move the device handlers to SCSI layer.

With that clarification....

Having device handlers in SCSI is useful _only_ if we have the appropriate device handler modules in initrd. Otherwise, the user will go thru all the sufferings (boot delay and error messages) that they went thru when the device handlers were in dm-layer voiding the very benefit of moving the handlers to SCSI layer.

As of today (actually since scsi dh was in the kernel), I suggest the users of scsi device handler modules to create a new initrd with the required scsi_dh module
(http://sources.redhat.com/lvm2/wiki/MultipathUsageGuide#head-fb3efbb82fa69ca86b7db26423c235ae6c280caa)

Ideal way to solve this problem is to make sure the appropriate/necessary modules are built into the initrd image automatically (as is the case with all other devices that need a driver), without the user/admin doing it .

Hence this patch.

Quoted 5 lines

The only value it adds is that by overloading the module table with the inquiry strings, mkinitrd pulls in the correct dm handlers for the state the system was in.

Quoted 8 lines

the unaddressed problems are:

The kernel now tries to load the dm handler for the device dynamically whether or not the user is actually deploying multi-path (previously dm does this and if it's not loaded, that doesn't happen). It's entirely unclear whether this would interfere with proprietary multipath handlers or even cause problems in single path systems which were designed that way.

This is by design (of SCSI DH). We do want the device to be attached to its handler _irrespective_ of whether multipath comes along or not.

BTW, there is _no_ infrastructure in multipath for handlers. They were removed from multipath when scsi dh came along. So, no worries about proprietary multipath handlers. Also, multipath _can_ attach a device to a different (SCSI) device handler if it finds that the one that is already attached is not the right one.

SCSI DH is implemented to make accessing the devices better (as is the case with any device specific driver over generic one). So, the effect of scsi dh handler on single path system is towards betterment than being problematic.

Quoted 3 lines

So as I see it, the functional benefit to a running kernel is zero and the functional risk exists but is unquantified, so it seems far better simply to solve this issue in mkinitrd.

I do not agree. This functionality makes the scsi devices behave the same way as the other devices, and hence make the system admin's life easier.

I hope you consider this feature in a better light now :)

chandra

Quoted 4 lines

James