Another use for block-layer timeouts

[Matthew Wilcox <matthew@wil.cx>]

On Wed, Nov 07, 2007 at 02:22:57PM +0100, Jens Axboe wrote:
> On Tue, Nov 06 2007, malahal@us.ibm.com 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."