mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: John Garry <john.garry@huawei.com>
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>
Subject: Re: [PATCH] scsi: Delete scsi_{get,free}_host_dev()
Date: Tue, 29 Jun 2021 09:15:37 +0100	[thread overview]
Message-ID: <77afd764-4195-188d-ef0e-c4adcfa38f8b@huawei.com> (raw)
In-Reply-To: <044a31ed-f6e9-3017-4973-3a02765933e0@suse.de>

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

      reply	other threads:[~2021-06-29  8:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-25 16:58 John Garry
2021-06-25 17:58 ` Bart Van Assche
2021-06-26 11:55 ` Hannes Reinecke
2021-06-29  8:15   ` John Garry [this message]

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=77afd764-4195-188d-ef0e-c4adcfa38f8b@huawei.com \
    --to=john.garry@huawei.com \
    --cc=bvanassche@acm.org \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=jejb@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=ming.lei@redhat.com \
    /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

all inboxes | Powered by JetHome®