From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Snitzer Subject: Re: [PATCH 2/2] dm-mpath: Remove useless retain_attached_hw_handler parameter Date: Mon, 28 Nov 2016 16:39:07 -0500 Message-ID: <20161128213907.GB7844@redhat.com> References: <1479971509-6320-1-git-send-email-tang.junhui@zte.com.cn> <1479971509-6320-2-git-send-email-tang.junhui@zte.com.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1479971509-6320-2-git-send-email-tang.junhui@zte.com.cn> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: tang.junhui@zte.com.cn Cc: zhang.kai16@zte.com.cn, dm-devel@redhat.com, agk@redhat.com List-Id: dm-devel.ids On Thu, Nov 24 2016 at 2:11am -0500, tang.junhui@zte.com.cn wrote: > From: "tang.junhui" > > Hardware handle would be retained no matter parameter > retain_attached_hw_handler is set or not in the logic > of current code. So remove this useless parameter. Right, that wasn't always the case. Previously (before commit ) dm-mpath would first detach the attached handler. I'm not completely opposed to removing the code that checks MPATHF_RETAIN_ATTACHED_HW_HANDLER in parse_path() but your proposed patch is broken in 2 ways: 1) in parse_path() you need to always initialize q 2) setting m->hw_handler_name to attached_handler_name needs to still happen regardless of whether m->hw_handler_name was previously set 3) the "retain_attached_hw_handler" feature should still be allowed on the command line, no sense to break multipath-tools But honestly, I'm not seeing any reason to not just leave the existing code.