On Wed, Nov 07, 2007 at 02:22:57PM +0100, Jens Axboe wrote: > On Tue, Nov 06 2007, malahal@xxxxxxxxxx wrote: > > gdth driver is modified NOT to use scp->eh_timeout. Now, it has > > eh_timed_out (gdth_timed_out) to handle command timeouts for locked > > I/O's. Have not tested as I don't have needed hardware! Patch is > > against 2.6.23-mm1. > > I updated the timeout patch to current kernel and fixed some fallout. I > included your gdth patch. > > Completely untested, patch is below. It's also in the #timeout branch of > the block git repo, to keep track of it. Hi Jens, Kristen, Sarah and I were talking over lunch today, and discovered that they each have a problem that I think can be solved by using the block layer timeout functionality. One problem is a software-controlled drive activity LED. The other is wanting to save power by suspending the link to an idle USB Storage device. What these both have in common is the desire to find out when the queue is empty (with a bit of hysteresis to avoid flickering the LED off for too long, or powering down the USB link when there's a command about to arrive). I think this could be done with the timer you're adding here, by adding a driver callback to be called once the timer fires and there's no commands in the queue. Alternatively, we could add another timer. While each driver could have its own timer to detect these cases, if we have two drivers that want this information, chances are there are others that could also make use of it. What do you think? Shall I try knocking up a patch to (ab)use the timer in this way? -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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
