On Mon, Oct 12, 2015 at 10:39 AM, Christoph Hellwig <hch@xxxxxx> wrote: > On Mon, Oct 12, 2015 at 02:45:38PM +0200, Hannes Reinecke wrote: >> 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. > > You can have two struct devices in struct scsi_device, while it's > not pretty there are plenty of example all over the kernel with > multiple devices in a single containing structure. > >> 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. > > Fine with me. As mentioned before we've never supported autoloading > the device handler modules at boot time - we only ever loaded them when > explicitly attaching them through device mapper. Waiting another > release or maybe two to finally get there isn't the end of the world. What may be getting lost during this discussion is that historically it has been important to be able to attach the scsi_dh during the SCSI scan. As the scsi_dh alters the SCSI midlayer's sense code processing (via callout to the attached scsi_dh). And this altered SCSI sense code handling amounts to the difference between a successful/quick boot versus hugely delayed and ultimately error-prone boot on systems with many LUNs that have multiple paths. So that is why either of these solutions were deployed: 1) in RHEL6 we'd require dracut to preload the scsi_dh modules early in loading the initramfs 2) in RHEL7 all scsi_dh modules _are_ builtin Both achieve the goal of having all required scsi_dh available during SCSI scan. Mike -- 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
