From: James Bottomley <James.Bottomley@steeleye.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "Justin T. Gibbs" <gibbs@scsiguy.com>,
SCSI Mailing List <linux-scsi@vger.kernel.org>,
Linus Torvalds <torvalds@transmeta.com>,
Marcelo Tosatti <marcelo@conectiva.com.br>,
Andrew Morton <akpm@osdl.org>
Subject: Re: Aic7x_x_x 6.3.4 && Aic79xx 2.0.5 Updates
Date: 27 Dec 2003 09:54:08 -0600 [thread overview]
Message-ID: <1072540449.2030.45.camel@mulgrave> (raw)
In-Reply-To: <1072538231.5494.12.camel@dhcp23.swansea.linux.org.uk>
On Sat, 2003-12-27 at 09:17, Alan Cox wrote:
> Or install your own EH handler. You don't have to use the kernel eh at
> all, you can just opt out of it and for some cards like smart raid
> devices its precisely the right thing to do. I can believe the argument
> that for fast failover you want to do EH differently, and nothing in the
> architecture seems to make that hard providing a driver is willing to
> opt cleanly out of the scsi_eh handler.
Well, that's what the eh_strategy_handler hook is for.
It certainly makes sense to do this for pseudo-scsi devices, like RAID
cards. But, for standard transports, like parallel SCSI and Fibre, I'd
much rather see a standardised error handling library as part of the
stack, with the mid-layer providing standard transport recovery
functions on a per-transport basis, and the Upper Layer Drivers
providing device specific handling.
> Similarly it would be nice to be able to revector the actual scsi eh
> timeouts via an optional handler. Something of the form
That's a good idea...do you want to send in the patches?
James
next prev parent reply other threads:[~2003-12-27 15:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-03 23:51 (unknown) Justin T. Gibbs
2003-06-03 23:51 ` Justin T. Gibbs
2003-06-03 23:58 ` Marc-Christian Petersen
2003-06-04 1:34 ` Aic7x_x_x 6.2.36 && Aic79xx 1.3.10 Updates Justin T. Gibbs
2003-12-24 16:58 ` Aic7x_x_x 6.3.4 && Aic79xx 2.0.5 Updates Justin T. Gibbs
2003-12-24 17:50 ` James Bottomley
[not found] ` <2148850000.1072292121@aslan.scsiguy.com>
2003-12-24 19:05 ` James Bottomley
2003-12-25 4:31 ` Justin T. Gibbs
2003-12-26 18:36 ` James Bottomley
2003-12-27 0:13 ` Justin T. Gibbs
2003-12-27 3:20 ` James Bottomley
2003-12-27 4:26 ` Justin T. Gibbs
2003-12-27 6:08 ` Jeff Garzik
2003-12-27 15:11 ` Alan Cox
2003-12-27 15:47 ` Justin T. Gibbs
2003-12-27 15:52 ` James Bottomley
2003-12-27 15:17 ` Alan Cox
2003-12-27 15:54 ` James Bottomley [this message]
2003-12-27 23:55 ` Alan Cox
2003-12-27 16:02 ` Justin T. Gibbs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1072540449.2030.45.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=gibbs@scsiguy.com \
--cc=linux-scsi@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.