Hello, Alan Stern! :-) Alan Stern wrote: > Even a "peek and fetch" interface might not be best, at least as far as > timer issues are concerned. Ideally, the timer shouldn't be started > until the SCSI midlayer knows that the request has successfully been > sent to the lower-level driver. > > Therefore the best approach would be to EXPORT blk_add_timer(). It > should be called at the end of scsi_dispatch_cmd(), when the return > value from the queuecommand method is known to be 0. > > With something like this, Mike's fix to end_that_request_last() > wouldn't be needed, since blkdev_dequeue_request() wouldn't > automatically start the timer. It seems silly to start the timer when > you know you're just going to stop it immediately afterwards. Block layer currently doesn't know when a request is actually being issued. For timeout, blk_add_timer() can be exported but I think that only aggravate the already highly fragmented block layer interface (different users use it differently to the point of scary chaos). For minor example, block tracing considers elv_next_request() as the command issue point which isn't quite true for SCSI and many other drivers. For that too, we can export the tracing interface but I don't think that's the right direction. More stuff are scheduled to be moved to block layer and exporting more and more implementation details to block layer users will have hard time scaling. I'm trying to convert all drivers to use the same command issue model - elv_next_request() -> blkdev_dequeue_request() on actual issue -> blk_end_request(). I have first draft of the conversion patchset but it's gonna take me a few more days to review and test what I can as several drivers (mostly legacy ones) are a bit tricky. For the time being, SCSI layer is the only block layer timeout user and completion w/o dequeuing is only for error cases in SCSI, so the inefficiency there shouldn't matter too much. Jens, what do you think? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
