N32 support in 64-bit MIPS Linux

N32 support in 64-bit MIPS Linux

[Kjeld Borch Egevang]

Hi all.

I would like to hear your opinion on this.

Currently we have the N64 interface which is the basic interface to the
kernel. Then we have the O32 interface which is implemented as a separate
set of syscalls in unistd.h and proper conversion in the kernel.

Now, how can we support N32? Many syscalls will work if N32 is treated the
same way as O32. This will of course mean, that O32 must be compiled in in
order to support N32. But e.g. a syscall like:

int _llseek(unsigned int fd, unsigned long offset_high, unsigned long 
offset_low, loff_t *result, unsigned int whence);

needs special treatment since loff_t is a long long (passed in a single
register for N32) and there are 6 arguments (all passed in registers for
N32, passed in registers and on the stack for O32).

Should we simply add 235 new syscall numbers to unistd.h named 
__NR_LinuxN32...?


/Kjeld


-- 
_    _ ____  ___                       Mailto:kjelde@mips.com
|\  /|||___)(___    MIPS Denmark       Direct: +45 44 86 55 85
| \/ |||    ____)   Lautrupvang 4 B    Switch: +45 44 86 55 55
  TECHNOLOGIES      DK-2750 Ballerup   Fax...: +45 44 86 55 56
                    Denmark            http://www.mips.com/

Re: N32 support in 64-bit MIPS Linux

[Ralf Baechle]

On Thu, Aug 15, 2002 at 12:06:31PM +0200, Kjeld Borch Egevang wrote:

> I would like to hear your opinion on this.
> 
> Currently we have the N64 interface which is the basic interface to the
> kernel. Then we have the O32 interface which is implemented as a separate
> set of syscalls in unistd.h and proper conversion in the kernel.
> 
> Now, how can we support N32? Many syscalls will work if N32 is treated the
> same way as O32. This will of course mean, that O32 must be compiled in in
> order to support N32. But e.g. a syscall like:
> 
> int _llseek(unsigned int fd, unsigned long offset_high, unsigned long 
> offset_low, loff_t *result, unsigned int whence);
> 
> needs special treatment since loff_t is a long long (passed in a single
> register for N32) and there are 6 arguments (all passed in registers for
> N32, passed in registers and on the stack for O32).
> 
> Should we simply add 235 new syscall numbers to unistd.h named 
> __NR_LinuxN32...?

o32 currently has 240 syscalls.  Of these a good number is simply
junk.  No syscall(2), oldstat(2), oldfstat(2), no experimental
UNIX Version 7 bs like mpx(2) for new ABIs; away with stupid multiplexor
calls like socketcall(2) and funny intelisms like vm86(2).  That's
the first cleanup I'm planning.

For what will be left over, N32 and N64 use the same subroutine calling
interface we'll be able to share most if not all syscalls between the two.
llseek(2) is just one example.

  Ralf

Re: N32 support in 64-bit MIPS Linux

[Kjeld Borch Egevang]

On Thu, 15 Aug 2002, Ralf Baechle wrote:

> On Thu, Aug 15, 2002 at 12:06:31PM +0200, Kjeld Borch Egevang wrote:
> 
> > I would like to hear your opinion on this.
> > 
> > Currently we have the N64 interface which is the basic interface to the
> > kernel. Then we have the O32 interface which is implemented as a separate
> > set of syscalls in unistd.h and proper conversion in the kernel.
> > 
> > Now, how can we support N32? Many syscalls will work if N32 is treated the
> > same way as O32. This will of course mean, that O32 must be compiled in in
> > order to support N32. But e.g. a syscall like:
> > 
> > int _llseek(unsigned int fd, unsigned long offset_high, unsigned long 
> > offset_low, loff_t *result, unsigned int whence);
> > 
> > needs special treatment since loff_t is a long long (passed in a single
> > register for N32) and there are 6 arguments (all passed in registers for
> > N32, passed in registers and on the stack for O32).
> > 
> > Should we simply add 235 new syscall numbers to unistd.h named 
> > __NR_LinuxN32...?
> 
> o32 currently has 240 syscalls.  Of these a good number is simply
> junk.  No syscall(2), oldstat(2), oldfstat(2), no experimental
> UNIX Version 7 bs like mpx(2) for new ABIs; away with stupid multiplexor
> calls like socketcall(2) and funny intelisms like vm86(2).  That's
> the first cleanup I'm planning.
> 
> For what will be left over, N32 and N64 use the same subroutine calling
> interface we'll be able to share most if not all syscalls between the two.
> llseek(2) is just one example.

Some syscalls will definitely not work for N32 with the N64 calling 
interface:

int execve(const char *filename, char *const argv [], char *const envp[]);

- where argv and envp points to arrays of pointers (4 bytes in N32, 8
  bytes in N64)

int fstat(int filedes, struct stat *buf);
int utime(const char *filename, struct utimbuf *buf);
clock_t times(struct tms *buf);
int ioctl(int d, int request, ...);
int fcntl(int fd, int cmd, struct flock * lock);

- struct contains long (4 bytes in N32, 8 bytes in N64)

So my point is, that we will need some of the O32 conversion stuff for N32 
as well.


/Kjeld


-- 
_    _ ____  ___                       Mailto:kjelde@mips.com
|\  /|||___)(___    MIPS Denmark       Direct: +45 44 86 55 85
| \/ |||    ____)   Lautrupvang 4 B    Switch: +45 44 86 55 55
  TECHNOLOGIES      DK-2750 Ballerup   Fax...: +45 44 86 55 56
                    Denmark            http://www.mips.com/