Re: [PATCH scsi-misc-2.6 08/08] scsi: fix hot unplug sequence

Tejun Heo
2005-03-25T21:43:54Z

Hello, James.

James Bottomley wrote:
> On Fri, 2005-03-25 at 14:38 +0900, Tejun Heo wrote:
>
>> We have users of scsi_do_req() other than scsi_wait_req() and they
>>use different done() functions to do different things. I've checked
>>other done functions and none uses contents inside the passed
>>scsi_cmnd, so using a dummy command should be okay with them. Am I
>>missing something here?
>
>
> Well ... the other users are supposed to be going away. They're
> actually all coded wrongly in some way or other ... perhaps I should
> speed up the process.

Sounds great. :-)

>> Oh, and I would really appreciate if you can fill me in / give a
>>pointer about the scsi_request/scsi_cmnd distinction.
>
> The block layer speaks in terms of requests and the scsi layers in terms
> of commands. The scsi_request_fn() actually associates a request with a
> command. However, since SCSI uses the block layer for queueing, all the
> internal scsi command submit paths have to use requests. This is what a
> scsi_request is. The reason for the special casing is that we can't use
> the normal REQ_CMD or REQ_BLOCK_PC paths because they need ULD
> initialisation and back end processing.

What I meant was we could just use scsi_cmnd instead of scsi_request
for commands. Currently, we do the following for special commands.

1. Allocate scsi_request and request (two are linked)
2. Initialize scsi_request as needed
3. queue the request
4. the request is dispatched
5. scsi_cmnd is initialized from scsi_request
6. scsi_cmnd is executed
7. result code and sense copied back to scsi_request
8. request is completed

Instead, we can

1. Allocate scsi_cmnd and request (two are linked)
2. Initialize scsi_cmnd as needed
3. queue the request
4. the request is dispatched
5. scsi_cmnd is executed
6. request is completed

As the latter seemed more straight-forward to me, I was wondering if
there were reasons that I wasn't aware of.

Thanks.

--
tejun