On Tue, Mar 24, 2026 at 03:12:38PM +0000, John Garry wrote: > On 24/03/2026 13:58, Benjamin Marzinski wrote: > > > > If it allowed device handlers to get attached, these two > > > > developement efforts (native scsi multipath and refactoring the alua > > > > support) could go on in parallel. > > > > > > > > Or am I missing something here? > > > It just seems to be about this DH stuff is that there is bad history there > > > and no more users are wanted. > > Just to be clear, if the idea was that the Native Multipath code > > shouldn't use include/scsi/scsi_dh.h, I completely agree with that. But > > I don't see why it can't make use of the results of the existing > > implicit ALUA support, since IIUC it doesn't need the scsi_dh interface > > to do that. > > We would need something like the following to ensure that DH ALUA is present > to update sdev access_state: > > @@ -80,6 +80,7 @@ config SCSI_MULTIPATH > bool "SCSI multipath support" > depends on SCSI_MOD > select LIBMULTIPATH > + select SCSI_DH_ALUA > help > This option enables support for native SCSI multipath support for > SCSI host.
DM_MULTIPATH doesn't force the device handlers to be built. You just don't have their support if they aren't there. Granted, it does make sure that if they are built, you can't build dm-multipath directly into the kernel, if the device handlers are built as modules. > > And that is even enough, as Kconfigs should only specify build requirements. > > We really should be also calling something like scsi_dh_attach() for scsi > multipath to ensure that DH is attached (and running to update > sdev->access_state). That isn't necessary. If there is an alua device handler, kernel will auto-attach it to any device that supports alua (see scsi_dh_add_device and scsi_dh_find_driver). DM-multipath's calling of scsi_dh_attach() is mostly a historical relic. > And I am not sure how the dh alua module is even autoloaded. I think that on > my ubuntu machine the multipath-tools.service does it - something like this > would not be nice for native SCSI multipath support. Fair point. Depending on how the kernel is built, there could be system configuration work that needs to happen if implicit alua support wasn't in the generic scsi code. But as far as the kernel code goes, I still see them as parallel efforts. -Ben > That shouldn't interfere with any refactoring that people > > want to do of how the scsi layer actually handles ALUA support. Again, > > this is more for Hannes than you, John. > > Thanks, > John
