On Wed, 2009-03-18 at 21:24 +0100, Kay Sievers wrote: > On Wed, Mar 18, 2009 at 21:09, James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, 2009-03-18 at 12:12 -0700, Chandra Seetharaman wrote: > >> On Wed, 2009-03-18 at 18:47 +0000, James Bottomley wrote: > >> > On Tue, 2009-03-17 at 18:36 -0700, Chandra Seetharaman wrote: > >> > > From: Peter Jones <pjones@xxxxxxxxxx> > >> > > > >> > > This patch allows the use of modaliases on scsi targets to correctly > >> > > load scsi device handler modules when the devices are found. > >> > > > >> > > Signed-off-by: Peter Jones <pjones@xxxxxxxxxx> > >> > > Signed-off-by: Chandra Seetharaman <sekharan@xxxxxxxxxx> > >> > > >> > I have to say this is a bit icky. > >> > > >> > overloading the modalias type like this produces several nasty effects: > >> > > >> > 1. You don't actually care about type for any of the scsi_dh > >> > handlers, so they all have it as a useless extra field > >> > 2. TYPE_ANY is a bogus (non SAM) definition ... I suppose it's > >> > unlikely ever to clash, but you never know > >> > >> >From (1) and (2) are you suggesting _not_ to use the TYPE field for > >> scsi_dh handlers ? > > > > Well, you don't ever set it to anything other than TYPE_ANY, do you? so > > it's completely superfluous as far as you're concerned. That's why > > overloading the SCSI ULD modalias looks rather contrived. > > > >> > 3. scsi_dh handlers would now get loaded on *any* system ... > >> > regardless of whether it's using multipathing or not ... that's > >> > going to cause problems with other multi path solutions, I bet. > >> > >> Actually that is the intent. We _do_ want scsi_dh handlers to be loaded > >> before multipath comes into picture. > >> > >> Basically we want the handlers to be available ASAP after the device is > >> configured. The reason is: > >> - These devices are active/passive, SCSI doesn't know about it and > >> any I/O sent to SCSI will be sent down to the device, irrespective > >> of the active/passive nature of the device in that path. When the > >> device (path) is passive, I/O leads to time delay and extraneous > >> error message (these are the two main reasons we moved the > >> device handler code from dm-multipath layer to SCSI(scsi_dh)). > >> > >> With scsi_dh, I/O to the passive path will be short circuited in > >> prep_fn() and errors are REQ_QUIET'd. > >> > >> Currently I suggest users to add these modules to their initrd to make > >> them available ASAP (as described at > >> http://sources.redhat.com/lvm2/wiki/MultipathUsageGuide#head-fb3efbb82fa69ca86b7db26423c235ae6c280caa) > >> > >> If we have the support thru modalias, then appropriate modules will be > >> included in initrd by the installer, thereby making it easier for the > >> user. > > > > Um, is that correct? the MODALIAS env is lost as soon as it goes > > through udev. For initrd to base module selection on the MODALIAS, it > > will have to reconstruct it after the fact (and so need modifying to use > > the new modalias). > > A device's modalias is usually also available as an attribute called > "modalias". The entire device uevent environment is in almost all > cases also available by reading the "uevent" file of the device at any > time later. > > Does that help? I might misread your "MODALIAS env is lost" sentence. Yes .. I'd forgotten that; I was thinking of the environment as it passes through udev. James -- 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
