From: Matthew Wilcox <willy@debian.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Hironobu Ishii <ishii.hironobu@jp.fujitsu.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-ia64 <linux-ia64@vger.kernel.org>
Subject: Re: [RFC/PATCH, 2/4] readX_check() performance evaluation
Date: Wed, 28 Jan 2004 18:20:03 +0000 [thread overview]
Message-ID: <20040128182003.GL11844@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <Pine.LNX.4.58.0401271847440.10794@home.osdl.org>
On Tue, Jan 27, 2004 at 06:55:17PM -0800, Linus Torvalds wrote:
> Quite frankly, I'd much rather have something more like this:
>
> clear_pcix_errors(dev);
> ..
> x = readX_check(dev, offset); /* Maybe several ones, maybe in a loop */
> ..
> error = read_pcix_errors(dev);
> if (error)
> take_pcix_offline(dev);
>
> in other words, I'd rather _not_ see the "readX_check()" code itself have
> the retry logic and error value handling.
>
> Why? Because on a number of architectures it is entirely possible that the
> error comes as a _asynchronous_ machine exception or similar. So I'd much
> rather have the interfaces be designed for that. Also, it's likely to
> perform a lot better, and result in much clearer code this way (ie you can
> try to set up the whole command before reading the error just once).
Well, read() is a bad example for that -- errors are always going
to come back straight away for a read. write() is a better example.
I'd really like to hear from someone who's done this kind of thing before.
Are there any actions worth taking when an error occurs *other* than
taking the card offline and notifying the user?
If there are, Linus' interface is probably the best one. If not, we could
simply have readX_check() / writeX_check() call dev->driver->unregister()
if they notice an error has occurred and then the driver doesn't even
need to call read_pcix_errors().
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
next prev parent reply other threads:[~2004-01-28 18:20 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-28 1:54 [RFC/PATCH, 2/4] readX_check() performance evaluation Hironobu Ishii
2004-01-28 1:54 ` Hironobu Ishii
2004-01-28 2:55 ` Linus Torvalds
2004-01-28 2:55 ` Linus Torvalds
2004-01-28 4:44 ` Paul Mackerras
2004-01-28 4:44 ` Paul Mackerras
2004-01-28 8:58 ` Russell King
2004-01-28 16:15 ` Linus Torvalds
2004-01-28 16:15 ` Linus Torvalds
2004-01-28 17:01 ` Grant Grundler
2004-01-28 17:01 ` Grant Grundler
2004-01-28 18:20 ` Matthew Wilcox [this message]
2004-01-28 19:19 ` Andi Kleen
2004-01-28 19:19 ` Andi Kleen
2004-01-28 19:33 ` Linus Torvalds
2004-01-28 19:33 ` Linus Torvalds
2004-01-28 19:40 ` Andi Kleen
2004-01-28 19:40 ` Andi Kleen
2004-01-28 20:06 ` Linus Torvalds
2004-01-28 20:06 ` Linus Torvalds
2004-01-28 20:15 ` Andi Kleen
2004-01-28 20:15 ` Andi Kleen
2004-01-28 20:19 ` [RFC/PATCH, 2/4] readX_check() performance evaluation II Andi Kleen
2004-01-28 20:19 ` Andi Kleen
2004-01-28 20:28 ` [RFC/PATCH, 2/4] readX_check() performance evaluation Linus Torvalds
2004-01-28 20:28 ` Linus Torvalds
2004-01-28 20:30 ` Linus Torvalds
2004-01-28 20:30 ` Linus Torvalds
2004-01-28 21:09 ` Andi Kleen
2004-01-28 21:09 ` Andi Kleen
2004-01-28 21:43 ` Linus Torvalds
2004-01-28 21:43 ` Linus Torvalds
2004-01-28 21:52 ` Andi Kleen
2004-01-28 21:52 ` Andi Kleen
2004-01-28 22:21 ` Linus Torvalds
2004-01-28 22:21 ` Linus Torvalds
2004-01-28 22:39 ` Andi Kleen
2004-01-28 22:39 ` Andi Kleen
2004-01-28 22:59 ` Linus Torvalds
2004-01-28 22:59 ` Linus Torvalds
2004-01-29 12:24 ` Hironobu Ishii
2004-01-29 12:24 ` Hironobu Ishii
2004-01-28 22:15 ` David S. Miller
2004-01-28 22:15 ` David S. Miller
2004-01-28 3:09 ` Matthew Wilcox
2004-01-28 3:09 ` Matthew Wilcox
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=20040128182003.GL11844@parcelfarce.linux.theplanet.co.uk \
--to=willy@debian.org \
--cc=ishii.hironobu@jp.fujitsu.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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 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.