Re: Bugs in multipath scsi in 4.3-rc2

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2015-10-12 at 14:45 +0200, Hannes Reinecke wrote:
> On 10/04/2015 09:45 AM, Christoph Hellwig wrote:
> > On Fri, Oct 02, 2015 at 06:44:57AM -0700, James Bottomley wrote:
> >> I think I prefer restoring that to having to build in every dh module to
> >> get them to work.  If we take your proposed fix for the sync module load
> >> in the current scheme, any non-built in modules would never attach, so
> >> we'd be moving towards the conclusion that *every* device handler has to
> >> be non-modular.
> > 
> > You don't need to build every module in to make it work.  In 4.2 and earlier
> > we already only auto load modules when dm-multipath explicitly attaches
> > to them.  That will still work in 4.3+.  In fact we will now autoload
> > when activating through sysfs as well.  With the change I sent to Paul
> > we still won't autoload at scan time, which would be really useful to have,
> > but wasn't implemented previously.
> > 
> >> Skimming the code it looks like dh should be using the driver binding
> >> model rather than reinventing it.  That would decouple it better and
> >> make sure binding happened regardless of when the module was loaded.
> > 
> > I tried this early on but gave up because I ran into too many problems.
> > I can try to give it a spin again.
> 
> You cannot easily use the driver model here as the scsi_device is
> already (potentially) bound to the ULDs.
> If you were to go with the driver model you'd have to introduce
> another sub device between scsi_target and scsi_device.

I was thinking more like what we do today for the ULD's: 3 of them use
the driver binding and one uses the class interface model.  Why can't we
also use the class interface model for dh?

James