Re: [PATCH 02/24] scsi-multipath: introduce basic SCSI device support

[John Garry <john.g.garry@oracle.com>]

On 03/03/2026 08:01, Hannes Reinecke wrote:
>> I would (perhaps naively) have thought that the device handlers would be
>> a useful abstraction for dealing with ALUA devices. But, Hannes knows
>> this code much better than me. like I said before, I'm no scsi expert.
>>
> The main point of the device handlers was to inject a 'start' command
> whenever paths needed to be switched (Like you need to do for some
> active/passive arrays).
> But that really caused quite some issues with complexity, as you easily
> can get into array path ping-pong on path failure with no I/O being 
> transmitted.
> 
> So for this implementation I would stick with implicit ALUA
> (most modern implementations have done so already anyway), and
> then there's no need using the device handlers.

I want to mention the problems of trying to not use device handler-based 
code from scsi_dh_alua.c . I would like to have core ALUA code for both 
scsi_dh_alua.c and native scsi multipath, but it's easier said than done 
to achieve.

I can easily extract the protocol-specific helper code, like alua_tur(), 
alua_check_tpgs(), and submit_rtpg().

But what about the port group management code, like in alua_rtpg() and 
alua_rtpg_work()? As far as I am concerned, we need that for native SCSI 
multipath support. All the port group management is intertwined with the 
DH stuff. Even stuff alua_port_group has DH stuff, like dh_list and 
rtpg_list members. And we also can't easily take code only relevant to 
implicit ALUA, either. Any suggestions?