Re: CVS Update@-mips.org: linux

[Ralf Baechle <ralf@linux-mips.org>]

On Tue, Jul 22, 2003 at 09:39:40PM +0200, Maciej W. Rozycki wrote:

> > sparc32 and sparc64 processors and systems are significantly
> > different.  For example, the SRMMU present in v8 CPUs is 100% replaced
> > with a totally different MMU (indeed, totally different instructions,
> > access methods, etc) in v9.  Accordingly there is very little code in
> > common between the two ports, and most of that is in device handling;
> > code that is in drivers/sbus and thus shared anyway.
> 
>  Well, the MMU of (original) 32-bit MIPS processors (i.e. R2k/R3k) is
> completely different from the one in later ones, too.  I suspect this is
> true for the R6k as well.  The exception handlers differ a bit as well,
> especially considering the XTLB refill one.  That probably counts as
> nitpicking, though... 

It's also a question of taste - and that one can be discussed forever.
How far do you want to factor our common code, as little as possible
which was our previous approach or extremly aggressive, glibc-like.

And yes, the R6000 is different.  With that in mind R2000 and R4000 look
like enzygotic twins ...

> > Something that made sense for sparc might not make sense for mips.
> 
>  Certainly it needs to be analysed on a case by case basis, avoiding
> blanket assumptions.  Anyway, I still see two reasons for having at least
> a separate top-level directory:
> 
> 1. A better separation of the more straightforward 32-bit Makefile and the
> more complicated 64-bit one.
> 
> 2. A better visual existence of the 64-bit port; not really a technical
> advantage, but more a psychological one.  It stops any newcomer wondering
> whether we support 64-bit systems natively or not. 

I was thinking about that also.  arch/mips64 and include/asm-mips64 will
go away but on the other side there will be an option to configure a
64-bit kernel in the menus - which will hopefully be more visible than
just two subdirectories.

>  There is also no point in having headers in asm-mips consisting of a
> single #ifdef CONFIG_MIPS32/#else/#endif conditional, where two distinct
> versions should be present in asm-mips and asm-mips64, respectively.  It's
> easier to make a diff between such separate implementations to verify
> everything's OK. 

Like 80% of the headers could be identical between both files without
lots of trickery.  The current approach is have two physical copies of
these identical files.

Btw, an old experience repeats - some of the code was identical except
inline assembler using addu etc. for 32-bit and daddu etc. for 64-bit.
I rewrote that stuff to use C for this arithmetic.  The result - less
inline assembler, more readable code and a file that's identical for
both 32-bit and 64-bit.

  Ralf