Re: [PATCH]: Flexible timeout infrastructure

[Luben Tuikov <luben_tuikov@adaptec.com>]

Christoph Hellwig wrote:
> Well, the question is always what is so special about your driver that
> it doesn't benefit from beeing in a common library.  I've pulled more crap
> out of individual drivers than I'd ever want to imagine, and because of
> that I'm pretty much allergic against giving driver writers more control
> then nessecary.

We are *not* talking about programming here, recognizing patterns
and modularizing them.

We are talking about _recovery_.  And this method is OPTIONAL.

The mere _procedure_ which will get executed when eh_cmd_timed_out()
is called may *not* be always be readily "pulled out". It maybe a quirk
in the: transport; target (vendor, etc); LUN; HBA (vendor, etc), etc,
for which _only_ the LLDD would know.  It may also be a specific
interconnect _recovery_ (e.g. USB, iSCSI, RDMA).  It may also be
a specific _vendor_ recovery, as is possible for iSCSI.

This kind of thing you _cannot_ generalize and "pull out". Just sit
down with a vendor and write a LLDD and you will see that there's cases
where there's no way to pull this up into a nice generalized
method, because certain defects are not always known, or too complicated
or vendor specific or non-open, etc.  The possibilies are far too many
and touch far too many areas (hw bugs, fw bugs, protocol recovery,
vendor specific protocol recovery, etc).

This infrastructure is non-intrusive (minimal patch), optional,
and SCSI Core is still in control every step of the way.  It really
is not that big of a deal, but would make wonders to SCSI Core
in the hands of capable drivers.  Granted not all would be capable of
using this, but those that would be, would definitely _improve_ recovery.

-- 
Luben