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

[Tejun Heo]

 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/