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. Actually I have been thinking that, as it might make my life for the ALUA handler easier. However, this would be quite a largish redesign of the current handler infrastructure, pushing out my ALUA handler update even more. So I'd like to have the ALUA changes ironed out first and merged, and then work on a redesigned device handler infrastructure. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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