linux-mips
[Top] [All Lists]

Re: Kernel 2.6 for R4600 Indy

To: "Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: Kernel 2.6 for R4600 Indy
From: Ralf Baechle <ralf@linux-mips.org>
Date: Thu, 7 Oct 2004 14:28:09 +0200
Cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>, linux-mips@linux-mips.org
In-reply-to: <Pine.LNX.4.58L.0410052023170.26193@blysk.ds.pg.gda.pl>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <4152D58B.608@longlandclan.hopto.org> <20040923154855.GA2550@paradigm.rfc822.org> <20041002185057.GN21351@rembrandt.csv.ica.uni-stuttgart.de> <20041002204014.GO21351@rembrandt.csv.ica.uni-stuttgart.de> <Pine.LNX.4.58L.0410022213140.18388@blysk.ds.pg.gda.pl> <20041004145244.GB8198@linux-mips.org> <Pine.LNX.4.58L.0410050044510.14763@blysk.ds.pg.gda.pl> <20041005190408.GD2160@linux-mips.org> <Pine.LNX.4.58L.0410052023170.26193@blysk.ds.pg.gda.pl>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4.1i
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

<Prev in Thread] Current Thread [Next in Thread>