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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
