On Fri, 25 Mar 2005, 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. > I have seen you mention this several times now and I am getting more and more worried. The reason is that scsi_wait_req() is a synchronous interface and it does not allow a driver to do this:
- send a request - do other useful things/let the user do useful work - wait for completion before starting another request I fully agree that doing done() correctly _is_ a problem, especially when the SCSI subsystem evolves and the high-level driver writers do not follow the development closely enough. One solution to these problems would be to let the drivers still use scsi_do_req() and their own done() function, but create two (three) helpers: - one to be called at the beginning of done(); it would do what needs to be done here but lets the driver to do some special things of its own if necessary - one to be called to wait for the request to finish (- one to do scsi_ro_req() and the things necessary before these) Having these helpers would isolate the user of the SCSI subsystem from the internals. scsi_wait_req() should call these functions and no additional maintenance would be needed for this additional asynchronous interface. The current drivers may not do any work in done() that could not be done later but there is one patch pending where this happens: the st performance statistics patch needs to get the time stamp when the SCSI command is processed. -- Kai - 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/