Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH] scsi: Delete scsi_{get,free}_host_dev()
To:     Hannes Reinecke <hare@suse.de>, <martin.petersen@oracle.com>,
        <jejb@linux.ibm.com>
CC:     <bvanassche@acm.org>, <linux-scsi@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <hch@lst.de>, <ming.lei@redhat.com>
References: <1624640314-93055-1-git-send-email-john.garry@huawei.com>
 <044a31ed-f6e9-3017-4973-3a02765933e0@suse.de>
From:   John Garry <john.garry@huawei.com>
Message-ID: <77afd764-4195-188d-ef0e-c4adcfa38f8b@huawei.com>
Date:   Tue, 29 Jun 2021 09:15:37 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.1.2
MIME-Version: 1.0
In-Reply-To: <044a31ed-f6e9-3017-4973-3a02765933e0@suse.de>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 26/06/2021 12:55, Hannes Reinecke wrote:
> On 6/25/21 6:58 PM, John Garry wrote:
>> Functions scsi_{get,free}_host_dev() no longer have any in-tree users, so
>> delete them.
>>
>> Signed-off-by: John Garry <john.garry@huawei.com>
>> ---
>> An alt agenda of this patch is to get clarification on whether this API
>> should be used for Hannes' reserved commands series.
>>
>> Originally the recommendation was to use it, but now it seems to be to
>> not use it:
>> https://lore.kernel.org/linux-scsi/55918d68-7385-0153-0bd9-d822d3ce4c21@suse.de/ 
>>
>>
> Please don't.

ok, we can take that as a nacked-by for now.

> 
> Before we're doing something like this I would like to have 
> clarification from Christoph which way he prefers for reserved commands. 
> Personally I _do_ like the host dev approach for reserved commands as it 
> allows us to re-use existing infrastructure.

So when you deleted the gdth driver, the request there was to delete 
this API. And in the v8 series, again, the request was not to use it, 
and use the dedicated request queue instead - I do know that this 
conflicts with the much earlier suggestion not to do that, but that was 
when gdth existed.

As for reuse of existing infrastructure, using this API seems to add 
more code than it reuses.

So don't we just need to add a dedicated request_queue for host? I don't 
know the use in having the scsi_device. Having said all that, we don't 
seem to have a host request_queue sysfs entry with either solution, 
which would be good.

> 
> Christoph?
> 

Thanks,
John