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: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-03 23:51 (unknown) 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox