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/
