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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]