public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Marzinski <bmarzins@redhat.com>
To: John Garry <john.g.garry@oracle.com>
Cc: martin.petersen@oracle.com,
	james.bottomley@hansenpartnership.com, hare@suse.com,
	jmeneghi@redhat.com, linux-scsi@vger.kernel.org,
	michael.christie@oracle.com, snitzer@kernel.org,
	dm-devel@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/13] scsi: Core ALUA driver
Date: Tue, 24 Mar 2026 11:48:43 -0400	[thread overview]
Message-ID: <acKyW6IPMhhZ_eF8@redhat.com> (raw)
In-Reply-To: <2f84e35f-3574-45e8-9567-4edcfdbe5a45@oracle.com>

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


  reply	other threads:[~2026-03-24 15:48 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-17 12:06 [PATCH 00/13] scsi: Core ALUA driver John Garry
2026-03-17 12:06 ` [PATCH 01/13] scsi: scsi_dh_alua: Delete alua_port_group John Garry
2026-03-18  7:44   ` Hannes Reinecke
2026-03-18  8:53     ` John Garry
2026-03-23  0:08   ` Benjamin Marzinski
2026-03-23 10:33     ` John Garry
2026-03-23 16:15       ` Benjamin Marzinski
2026-03-23 18:07         ` John Garry
2026-03-17 12:06 ` [PATCH 02/13] scsi: alua: Create a core ALUA driver John Garry
2026-03-18  7:47   ` Hannes Reinecke
2026-03-23 12:56     ` John Garry
2026-03-18 17:17   ` kernel test robot
2026-03-18 22:54   ` kernel test robot
2026-03-17 12:06 ` [PATCH 03/13] scsi: alua: Add scsi_alua_rtpg() John Garry
2026-03-18  7:50   ` Hannes Reinecke
2026-03-23 12:58     ` John Garry
2026-03-17 12:06 ` [PATCH 04/13] scsi: alua: Add scsi_alua_stpg() John Garry
2026-03-18  7:53   ` Hannes Reinecke
2026-03-17 12:06 ` [PATCH 05/13] scsi: alua: Add scsi_alua_tur() John Garry
2026-03-18  7:54   ` Hannes Reinecke
2026-03-23 13:42     ` John Garry
2026-03-24 10:49       ` John Garry
2026-03-17 12:06 ` [PATCH 06/13] scsi: alua: Add scsi_alua_rtpg_run() John Garry
2026-03-17 12:06 ` [PATCH 07/13] scsi: alua: Add scsi_alua_stpg_run() John Garry
2026-03-18  7:57   ` Hannes Reinecke
2026-03-18  8:59     ` John Garry
2026-03-18  9:24       ` Hannes Reinecke
2026-03-23 13:58         ` John Garry
2026-03-17 12:06 ` [PATCH 08/13] scsi: alua: Add scsi_alua_check_tpgs() John Garry
2026-03-18  7:57   ` Hannes Reinecke
2026-03-17 12:06 ` [PATCH 09/13] scsi: alua: Add scsi_alua_handle_state_transition() John Garry
2026-03-18  7:58   ` Hannes Reinecke
2026-03-23 13:43     ` John Garry
2026-03-17 12:07 ` [PATCH 10/13] scsi: alua: Add scsi_alua_prep_fn() John Garry
2026-03-18  8:01   ` Hannes Reinecke
2026-03-23 13:49     ` John Garry
2026-03-17 12:07 ` [PATCH 11/13] scsi: alua: Add scsi_device_alua_implicit() John Garry
2026-03-18  8:02   ` Hannes Reinecke
2026-03-23 13:50     ` John Garry
2026-03-17 12:07 ` [PATCH 12/13] scsi: scsi_dh_alua: Switch to use core support John Garry
2026-03-23  1:47   ` Benjamin Marzinski
2026-03-23 11:59     ` John Garry
2026-03-17 12:07 ` [PATCH 13/13] scsi: core: Add implicit ALUA support John Garry
2026-03-18  8:08   ` Hannes Reinecke
2026-03-18 23:08   ` kernel test robot
2026-03-23  1:58   ` Benjamin Marzinski
2026-03-23 12:52     ` John Garry
2026-03-23 17:29       ` Benjamin Marzinski
2026-03-23 18:13         ` John Garry
2026-03-22 17:37 ` [PATCH 00/13] scsi: Core ALUA driver Benjamin Marzinski
2026-03-23  9:57   ` John Garry
2026-03-23 16:25     ` Benjamin Marzinski
2026-03-23 18:04       ` John Garry
2026-03-23 19:45         ` Benjamin Marzinski
2026-03-24 10:57           ` John Garry
2026-03-24 13:58             ` Benjamin Marzinski
2026-03-24 15:12               ` John Garry
2026-03-24 15:48                 ` Benjamin Marzinski [this message]
2026-03-24 16:25                   ` John Garry
2026-03-26 10:19                 ` Hannes Reinecke
2026-03-26 12:16                   ` John Garry
2026-03-27  7:02                     ` Hannes Reinecke
2026-03-26 10:17               ` Hannes Reinecke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acKyW6IPMhhZ_eF8@redhat.com \
    --to=bmarzins@redhat.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=hare@suse.com \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=jmeneghi@redhat.com \
    --cc=john.g.garry@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=michael.christie@oracle.com \
    --cc=snitzer@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox