On Wed, Jan 09, 2002 at 09:59:32PM +0100, Emmanuel Dreyfus wrote:

 > Well, if I remove -Werror to get this problem corrected, I can build a
 > LP64 kernel. This kernel is able to boot, but because system calls are
 > completely broken, init dies quickly.

I seriously doubt it's an LP64 kernel.

 > In fact there is a padding problem because sizeof(register_t) is not
 > equal to sizeof(mips_regs_t), hence when you write(2, 0x7fff40b0, 6),
 > the kernel understands write(0, 2, 0).

The mips_reg_t should probably die in favor of actually using register_t
for everything.

 > In fact I'm surprised it's even able to create the init process, I
 > really expected fatal pmap problems.

If you're using 32-bit addresses, the pmap should still be "fine".  (Some
MIPS ports already use a 64-bit paddr_t).

 > To be honest I am. I'm now hang on o32 compatibility because of a
 > strange VM problem. I'd like to go foward with the system call
 > emulation, and n32 is an opportunity to do so. Hence I'd by happy to
 > have a LP64 kernel running just our current o32 userland and N32
 > binaries. Don't worry, I won't commit theses changes, I understood that
 > this is not The Right Way nor The Desired Way. 

Well, doing it as a bunch of quick hacks and "fixes" isn't the appropriate
way to go about this.  You're attacking the n32 problem in a very ad-hoc
way.  If you really want to support n32, then you should support it the
CORRECT way.

Honestly, what you should be doing is tracking down your o32 VM problem.

 > I don't need to be able to natively build N32 binaries in order to work
 > on IRIX n32 emulation... anyway, working on 64 bit support on the Mips
 > is an interesting project, and I'm okay to work on this too, so please
 > tell me where I can gather information about all the changes that need
 > to happen (I still have to buy 'see mips run')

No, you don't need to be able to build native n32 binaries, but you need
to be able to build a working n32-capable kernel.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>