Re: [PATCH]: Flexible timeout infrastructure

[James Bottomley <James.Bottomley@steeleye.com>]

On Tue, 2004-06-15 at 10:02, Luben Tuikov wrote:
> This patch introduces a flexible command timeout infrastructure
> accomodating completely current behaviour SCSI Core command timeout,
> but also offering the ability to hand command timeout handling to
> a LLDD, _yet_ still have it all go through *SCSI Core*.

But what this basically does is force any implementor of
eh_cmd_timed_out to handle all timers themselves.  Given that a large
number of driver writers who try to do this get it wrong (mostly around
del_timer() and del_timer_sync()), I don't think this is such a good
idea.

> This is somewhat similar to Christoph's proposal patch, but I wasn't
> aware of his patch when I thought of this. Interestingly enough it can be
> viewed as an extension to his patch.

This proposal was to allow LLD notification that the timer fired (rather
than first hearing about it when the eh activated).  I could see an
extension to this, like the return values you propose, where the LLD
tells the mid-layer that it corrected the command problem (in interrupt
context) and the command is ready for completion (otherwise proceed into
the eh).

Since we also already have the ability to modify the command times in
slave configure, is it really necessary to encourage the alteration of
SCSI timers in this way?

James