Wayne Knowles wrote:

> More than likely we can solve it under arch/mips/mips64 which is the way
> the ARM port headed for the arm26/arm32 differences.

I vote for it, too.

I would like to propose the following design direction;

NetBSD/mips
    - R3000 derivatives and
    - R4000 descenders in 32bit mode (includes MIPS32 like IDT
    RC32000)
    - runs 32bit user land which we have (O32 model in SGI's term)

NetBSD/mips64
    - requires 64bit processors
    - LP64 kernel
    - 64bit user land w/ 64bit FP (N64 model in SGI's term)
    - capable to run N32
    - might run O32

The kerenl code differences between two are expected so small
(compared to multiple generations of SPARC, ARM or PPC) that
it'd be justified to share arch/mips/ directory.  Significant
differences would make locore.S, pmap.c and trap.c apart
from 32bit implementation while others might be absorbed by
well-controlled #ifdef's.

The issue here is it might be burden to mandate 64bit kernel to run
N32 applications.  It might be necessary to invent the third "standard"
32bit-kernel-to-run N32, which is trivially attractive for embeded
things,  however, not _that_ easy job (might be forgiven for
one-time drive-by shooting embeded products) and beyond hacking
of what we have this moment (I still believe in the introduction of
mips_reg_t was a fruitless mistake).

So, we need to discuss what NetBSD we really want to have for
64bit MIPS processor.  Say, what does Solaris provide for user
programming?  It's important to talk about, in particular, cross
64/32 border compiling environment.

Toru Nishimura