From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
linux-mips@linux-mips.org
Subject: Re: Kernel 2.6 for R4600 Indy
Date: Thu, 7 Oct 2004 14:28:09 +0200 [thread overview]
Message-ID: <20041007122809.GB32619@linux-mips.org> (raw)
In-Reply-To: <Pine.LNX.4.58L.0410052023170.26193@blysk.ds.pg.gda.pl>
On Tue, Oct 05, 2004 at 08:35:52PM +0100, Maciej W. Rozycki wrote:
> Well, the nearby comment agrees with me. Is the handler misused or has
> someone forgotten to fix the comment (yes, I do know of the R4700 and
> R4640/R4650, with the former being almost identical to the R4600 and the
> latters being unsupported due to lacking a TLB MMU)?
The names R4000 and R4k are at times used to mean any R4000-ish processor.
What that means in a particular context isn't always well defined. Even
an oddball processor like the R8000 may be covered ...
R5000 being the faster twin of the R4600 also uses it. Nevada only got it's
own handler due some processor bug; upto it's workaround this class of
processors also used the R4000 handler. With hazards.h the need for the
nop-free version for the R10000 family went away also, so it moved over to
the standard R4000 one. RM7000 was always using it and RM9000 having
slightly different hazards than it's predecessors never had a good reason
> is it worth the hassle? Or is the "plan" scheduled for around 2.8 or so?
Given the experience with clear_user / copy_user going for the runtime
generated handlers is relativly easy and can be done without alot of
breakage so it's more a question of somebody doing it and I'll not try
to stop any reasonable implementation.
Ralf
next prev parent reply other threads:[~2004-10-07 12:30 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-23 13:54 Kernel 2.6 for R4600 Indy Stuart Longland
2004-09-23 14:51 ` Ladislav Michl
2004-09-23 15:00 ` Stephen P. Becker
2004-09-24 0:16 ` Stuart Longland
2004-09-24 9:07 ` Florian Lohoff
2004-09-24 15:42 ` Stuart Longland
2004-09-24 16:44 ` Florian Lohoff
2004-09-24 13:05 ` Stephen P. Becker
2004-09-24 13:17 ` Robin Humble
2004-09-24 13:27 ` Stephen P. Becker
2004-09-24 13:43 ` Robin Humble
2004-09-24 15:13 ` Stephen P. Becker
2004-09-23 15:48 ` Florian Lohoff
2004-10-02 18:50 ` Thiemo Seufer
2004-10-02 20:40 ` Thiemo Seufer
2004-10-02 23:47 ` Thiemo Seufer
2004-10-03 0:58 ` Maciej W. Rozycki
2004-10-04 14:52 ` Ralf Baechle
2004-10-04 23:48 ` Maciej W. Rozycki
2004-10-05 19:04 ` Ralf Baechle
2004-10-05 19:35 ` Maciej W. Rozycki
2004-10-07 12:28 ` Ralf Baechle [this message]
2004-10-03 11:40 ` Thomas Bogendoerfer
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=20041007122809.GB32619@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=ica2_ts@csv.ica.uni-stuttgart.de \
--cc=linux-mips@linux-mips.org \
--cc=macro@linux-mips.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.