linux-mips
[Top] [All Lists]

Re: broken RM7000 in CVS

To: linux-mips@oss.sgi.com
Subject: Re: broken RM7000 in CVS
From: Justin Carlson <carlson@sibyte.com>
Date: Fri, 12 Jan 2001 13:54:49 -0800
Organization: Sibyte
Reply-to: carlson@sibyte.com
Sender: owner-linux-mips@oss.sgi.com
On Fri, 12 Jan 2001, you wrote:> Justin Carlson wrote:
> > Not if you want to have constant-defined offsets into the table.  Which is 
> > just
> > about the only reason to use a table for this...Either:
> > 
> 
> No, I am thinking to have constant-defined offset into the table.  Instead, I
> am thinking to do a linear search of the table and find a matching entry based
> on the PRID.
> 
> Without table, I can see two alternatives, 1) switch/case statement to fill in
> the data by statements (which is the current case) or 2) for each CPU
> (protected by #ifdef CONFIG_) we define a mips_cpu struct.
> 
> I guess I just like table better than switch/case statements.  Table seems
> cleaner to me.

You're not going to get rid of the big switch statement for older (non mips32)
processors because of the specialized checks to refine steppings, etc. 
as it is. 

I still would rather stick to the switch style of doing things in the future,
though, because it's a bit more flexible; if you've got companies that fix
errata without stepping PrID revisions or some such, then the table's going to
have some strange special cases that don't quite fit.

But this is much more workable than what I *thought* you were proposing.  And
not worth nearly as much trouble as I've been giving you over it.    

Luckily, in the end, you have to convince saner people than me.  :)

-Justin

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