Re: [PATCH]: Flexible timeout infrastructure

[Luben Tuikov <luben_tuikov@adaptec.com>]

> so do explain why the recovery method requires the midlayer to hand over
> timer handling to the driver ?

This is explained in the rest of the message (the part you cut off),
and also very well explained by Doug, another LLDD writer.

> Why does it matter for *recovery* who started
> the timer ???

But that's _exactly_ the point!  It's the different scenarios
of recovery, (hw bugs, sw bugs, vendor recovery logic as is allowable
in specific protocols, etc, etc, etc)  I'm basically repeating the
previous email I posted.

You cannot have an arbitrary timer running alongside LLDD recovery
logic.
 
> Yes I can see the use for the driver to tell the timer handler code "eh please
> give me some more time, I'm configuring stuff for a bit". But that doesn't
> explain why it shouldn't be the midlayer that keeps in charge of timer
> handling and solicits the advice from the driver like this..

But that's exactly what Doug's and my emails explained!  I'm confused!?
Is this some kind of game of asking the same questions in different forms?
It's as if my email wasn't read at all? And just the same question was asked
in a different form?  It wasn't like this 4 years ago.

Again, this is just a non-intrusive _optional_ method, which would allow
capable LLDD (and non-native interconnects) to use if they decide to do so.
As I said, work with a vendor to write a LLDD (especially for newer protocols)
and the _option_ of such a method would be clear.

Any LLDD writers, FC, iSCSI, SAS people, SCSI architects are welcome
to chime in.  This patch was really intended for such a discussion.

-- 
Luben