On Mon, Jan 28, 2019 at 03:14:19PM +0100, Hannes Reinecke wrote: > > The most straigthforward approach would be something like > 'blk_mq_get_private_request()' (ie similar to the existing > 'blk_mq_get_request()'). But that requires a working request queue and will > expose a 'struct request', (and by implication a struct scsi_cmnd). The same interface as we do in other block drivers: blk_mq_alloc_request with BLK_MQ_REQ_RESERVED. And yes, this gets us a struct scsi_cmnd, which is exactly what we need. > For most users of private tags/commands we need to be the queue working > _prior_ to setting up the 'normal' request queues, as the commands are used > to fetch information from the hardware required to setup the queues. > And typically the 'private' commands are driver-specific, ie the payload > _after_ the scsi command, so the allocation for the request and the scsi > command is pretty much pointless here. And in that case you want a request_queue that is host-wide for these commands as you obviously don't have the per-LU regular request_queues. We actually have a few uses like that in existing old SCSI drivers, where we create a fake struct scsi_device to send command to the host, which doesn't sound all that bad except for the fact that we need an escape for the lun value to avoid getting in the way. In general I'm not sure this is the most common use case - I'd expect the most common use to be proper implementing TMFs..
