[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200407163033.GA26568@infradead.org>
Date: Tue, 7 Apr 2020 09:30:33 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Hannes Reinecke <hare@...e.de>
Cc: John Garry <john.garry@...wei.com>,
Christoph Hellwig <hch@...radead.org>, axboe@...nel.dk,
jejb@...ux.ibm.com, martin.petersen@...cle.com,
ming.lei@...hat.com, bvanassche@....org,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-scsi@...r.kernel.org,
virtualization@...ts.linux-foundation.org,
esc.storagedev@...rosemi.com, chenxiang66@...ilicon.com,
Hannes Reinecke <hare@...e.com>
Subject: Re: [PATCH RFC v2 02/24] scsi: allocate separate queue for reserved
commands
On Tue, Apr 07, 2020 at 04:00:10PM +0200, Hannes Reinecke wrote:
> My concern is this:
>
> struct scsi_device *scsi_get_host_dev(struct Scsi_Host *shost)
> {
> [ .. ]
> starget = scsi_alloc_target(&shost->shost_gendev, 0, shost->this_id);
> [ .. ]
>
> and we have typically:
>
> drivers/scsi/hisi_sas/hisi_sas_v3_hw.c: .this_id = -1,
>
> It's _very_ uncommon to have a negative number as the SCSI target device; in
> fact, it _is_ an unsigned int already.
>
> But alright, I'll give it a go; let's see what I'll end up with.
But this shouldn't be exposed anywhere. And I prefer that over having
magic requests/scsi_cmnd that do not have a valid ->device pointer.
Powered by blists - more mailing lists