In message <20010716092924.O96667-100000@wonky.feral.com>,
Matthew Jacob writes:

>>>
>>> It's perhaps best in this case to let the target device driver decide, based
>>> on policy, whether it wants to wait for a period before it begins to start
>>> failing commands and then up to the caller's cleverness as to what it would
>>> like to do (detach, retry, fallback to alternate volumes, etc.).
>>
>> Hum, I think this should be in the core scsipi itself, not in upper
>> level drivers. It's better to have a consistent behavior for all devices.
>
>Oh, I suppose. I guess that because the target driver can reject a detach,
>then you can your shorts wrapped your ankles when that happen.
>
>Still, it's the target driver who really should be deciding how important a
>selection timeout is.

Yeah, but idiosyncratic per-driver timeouts with no or idiosyncratic
ways to change them leads to chaos.


Here's a strawman: keep timeout information in one consistent place in
the mid-layer, with

  1)  A global default
  2)  A callback for any hba instance to override the default for itself
     (Matt's "policy"),  and  a config-time message letting the user know
     the  HBA asserted its "policy".
  3)  A way to force  wired-down defaults in a wired-down kernel config

I'm thinking iSCSI...