Emmanuel,

It seems to me that the original focus to add IRIX compatability
(COMPAT_IRIX) is slowly changing into a crusade to enable (or justify)
64bit functionalty for the Mips processors.

Perhaps that is not the intent, but it is what is being interpreted from
the approach you are taking.

Your solution is currently in "flux", and there is not much evidence
that you have fully thought out the problems ahead or understand the
O32/N32/N64 ABI differences enough to gain the confidence that your
changes are the right way to go.

In case you missed it first time around - we cannot have N32 all over the
place because the R2000 and R3000 don't have 64 bit registers to play
with.

As previously mentioned, if the setregs_n32 function is placed in the
compat/irix sources a lot of the complaints will probably disappear.

It is only required by the compat_irix code and at this stage isn't shared
by other kernel subsystems.
Sometimes there are reasons why this rule is broken, including:
1)   The function is a defined MI <-> MD interface (hence the name
     mips_machdep.c) which is used by many ports
2)   Scope rules dictate that a better placement to access private data

Given that we have svr4_setregs() svr4_32_setregs() linux_setregs()
freebsd_setregs() hpux_setregs() all living happily in the compat tree, it
seems to me the compat_irix code should be able to do the same.

Several steps are required to get to mips64 support.   Seperating out the
MIPS1 and MIPS3 processors to make them more distinct (and ensure all
existing ports will operate) will probably be the first step of that
journey.   Changing (or adding another) ABI will be a little further along
that road.

The mips64 topic has been raised on this list before, and general
agreement is that there isn't any reason to change unless there is a
significant benefit.  This translates into having LP64 support along with
the necessary toolchain support.

-- 
Wayne Knowles			NetBSD/mipsco port maintainer
wdk@netbsd.org			http://www.netbsd.org