From: torvalds@transmeta.com (Linus Torvalds)
To: linux-kernel@vger.kernel.org
Subject: Re: Linux/Pro -- clusters
Date: Thu, 6 Dec 2001 16:58:34 +0000 (UTC) [thread overview]
Message-ID: <9uo83q$aa7$1@penguin.transmeta.com> (raw)
In-Reply-To: <9um58i$9no$1@penguin.transmeta.com> <E16BlnL-00080m-00@the-village.bc.nu>
In article <E16BlnL-00080m-00@the-village.bc.nu>,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
>You still need the scsi code. There are a whole sequence of common, quite
>complex and generic functions that the scsi layer handles (in paticular
>error handling).
Well, the preliminary patches already handle _some_ common things, like
building the proper command request for reads and writes etc, and that
will probably continue. We'll probably have to have all the old helpers
for things like "this target only wants to be probed on lun 0" etc.
I disagree about the error handling, though.
Traditionally, the timeouts and the reset handling was handled in the
SCSI mid-layer, and it was a complete and utter disaster. Different
hosts simply wanted so different behaviour that it's not even funny.
Timeouts for different commands were so different that people ended up
making most timeouts so long that they no longer made sense for other
commands etc.
Other device drivers have been able to handle timeouts and errors on
their own before, and have _not_ had the kinds of horrendous problems
that the SCSI layer has had.
We'll see what the details will end up being, but I personally think
that it is a major mistake to try to have generic error handling. The
only true generic thing is "this request finished successfully / with an
error", and _no_ high-level retries etc. It's up to the driver to decide
if retries make sense.
(Often retrying _doesn't_ make sense, because the firmware on the
high-end card or disk itself may already have done retries on its own,
and high-level error handling is nothing but a waste of time and causes
the error notification to be even more delayed).
Linus
next prev parent reply other threads:[~2001-12-06 17:05 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-03 18:12 Linux/Pro -- clusters Donald Becker
2001-12-04 1:55 ` Davide Libenzi
2001-12-04 2:09 ` Donald Becker
2001-12-04 2:23 ` Davide Libenzi
2001-12-04 2:34 ` Alexander Viro
2001-12-04 9:10 ` Alan Cox
2001-12-04 9:30 ` Thomas Langås
2001-12-04 9:45 ` Alan Cox
2001-12-04 11:34 ` Thomas Langås
2001-12-05 21:57 ` Linus Torvalds
2001-12-05 23:05 ` Andre Hedrick
2001-12-06 4:31 ` Daniel Phillips
2001-12-05 23:49 ` Alan Cox
2001-12-05 23:48 ` Andre Hedrick
2001-12-06 16:58 ` Linus Torvalds [this message]
2001-12-06 18:02 ` Alan Cox
2001-12-06 18:07 ` Linus Torvalds
2001-12-06 18:12 ` Kai Henningsen
2001-12-06 20:46 ` Linus Torvalds
2001-12-06 22:40 ` Alan Cox
2001-12-06 18:33 ` Alan Cox
2001-12-06 18:55 ` Linus Torvalds
2001-12-06 19:19 ` Alan Cox
2001-12-06 20:37 ` Linus Torvalds
2001-12-06 22:35 ` Alan Cox
2001-12-06 22:34 ` Linus Torvalds
2001-12-06 22:58 ` Alexander Viro
2001-12-07 10:14 ` Martin Dalecki
2001-12-07 10:37 ` Alan Cox
2001-12-07 10:56 ` Martin Dalecki
2001-12-07 12:08 ` Alan Cox
2001-12-07 20:51 ` On re-working the major/minor system Erik Andersen
2001-12-07 21:21 ` H. Peter Anvin
2001-12-07 21:55 ` Erik Andersen
2001-12-07 22:04 ` H. Peter Anvin
2001-12-07 23:07 ` Erik Andersen
2001-12-07 23:12 ` H. Peter Anvin
2001-12-08 11:42 ` Alan Cox
2001-12-08 20:37 ` H. Peter Anvin
2001-12-09 12:06 ` Kai Henningsen
2001-12-09 21:57 ` H. Peter Anvin
2001-12-11 20:45 ` Kai Henningsen
2001-12-06 18:38 ` Linux/Pro -- clusters Doug Ledford
2001-12-04 14:37 ` Daniel Phillips
2001-12-04 15:19 ` Jeff Garzik
2001-12-04 17:16 ` Daniel Phillips
2001-12-04 17:20 ` Jeff Garzik
2001-12-04 18:04 ` Alan Cox
2001-12-04 18:16 ` Daniel Phillips
2001-12-04 20:20 ` Andrew Morton
2001-12-05 13:11 ` Deep look into VFS Martin Dalecki
2001-12-05 15:19 ` Alexander Viro
2001-12-05 15:30 ` Martin Dalecki
-- strict thread matches above, loose matches on Subject: below --
2001-12-08 1:50 Linux/Pro -- clusters Andries.Brouwer
2001-12-08 3:42 ` H. Peter Anvin
2001-12-08 17:26 Andries.Brouwer
2001-12-09 4:22 ` Linus Torvalds
2001-12-09 5:49 ` Alexander Viro
2001-12-09 8:59 Andries.Brouwer
2001-12-10 16:49 ` Alexander Viro
2001-12-10 17:09 ` Alan Cox
2001-12-11 8:39 ` Albert D. Cahalan
2001-12-10 19:36 Andries.Brouwer
2001-12-10 22:55 ` Alexander Viro
2001-12-10 19:51 Andries.Brouwer
2001-12-10 20:34 ` Alan Cox
2001-12-10 21:31 Andries.Brouwer
2001-12-10 21:44 ` Alan Cox
2001-12-10 22:48 Andries.Brouwer
2001-12-10 23:33 Andries.Brouwer
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='9uo83q$aa7$1@penguin.transmeta.com' \
--to=torvalds@transmeta.com \
--cc=linux-kernel@vger.kernel.org \
/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