All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Re: 64-bit and N32 kernel interfaces
Date: Mon, 16 Sep 2002 15:01:52 +0200	[thread overview]
Message-ID: <20020916150152.A1677@linux-mips.org> (raw)
In-Reply-To: <20020904155645.A31893@linux-mips.org>; from ralf@linux-mips.org on Wed, Sep 04, 2002 at 03:56:45PM +0200

On Wed, Sep 04, 2002 at 03:56:45PM +0200, Ralf Baechle wrote:

Additional changes I've done to my working version:

> As first think I want to get rid of all the historic crap we have in
> our syscall tables for the 64-bit syscalls.  Let's start here:
> 
> #define __NR_syscall                    (__NR_Linux +   0)
> 
> Deprecated because can be implemented in userspace.
> 
> #define __NR_ioperm                     (__NR_Linux + 101)
> #define __NR_iopl                       (__NR_Linux + 110)
> #define __NR_vm86                       (__NR_Linux + 113)
> 
> i386 braindamage we're never going to support.  So why have it in our
> syscall table?
> 
> #define __NR_unused59                   (__NR_Linux +  59)
> #define __NR_reserved82                 (__NR_Linux +  82)
> #define __NR_unused109                  (__NR_Linux + 109)
> #define __NR_unused150                  (__NR_Linux + 150)
> 
> Unused entries.  Why keep them ...
> 
> #define __NR_break                      (__NR_Linux +  17)
> #define __NR_stty                       (__NR_Linux +  31)
> #define __NR_gtty                       (__NR_Linux +  32)
> #define __NR_ftime                      (__NR_Linux +  35)
> #define __NR_prof                       (__NR_Linux +  44)
> #define __NR_signal                     (__NR_Linux +  48)
> #define __NR_mpx                        (__NR_Linux +  56)
> #define __NR_ulimit                     (__NR_Linux +  58)
> #define __NR_readdir                    (__NR_Linux +  89)
> #define __NR_profil                     (__NR_Linux +  98)
> #define __NR_modify_ldt                 (__NR_Linux + 123)

One more for the same cathegory:

#define __NR_lock                       (__NR_Linux +  53)

> Slots that data back to day one of UNIX way before Linux was born.
> 
> #define __NR_socketcall                 (__NR_Linux + 102)
> 
> Wrapper syscall, obsoleted since quite a while in the 32-bit kernel.
> 
> #define __NR_idle                       (__NR_Linux + 112)
> 
> Internal syscall, no longer used.
> 
> #define __NR_ipc                        (__NR_Linux + 117)

This implies eleven new entries for:

__NR_semget
__NR_semop
__NR_semctl
__NR_msgget
__NR_msgsnd
__NR_msgrcv
__NR_msgctl
__NR_shmget
__NR_shmat
__NR_shmdt
__NR_shmctl

> Yet another multiplexor syscall and imho another candidate for getting
> rid of.
> 
> #define __NR_oldstat                    (__NR_Linux +  18)
> #define __NR_umount                     (__NR_Linux +  22)
> #define __NR_oldfstat                   (__NR_Linux +  28)
> #define __NR_oldlstat                   (__NR_Linux +  84)
> 
> Superseeded by newer versions.
> 
> #define __NR_uselib                     (__NR_Linux +  86)
> 
> a.out support.  Do we really want that.
> 
> I probably missed a few.  The primary purpose of this posting is to get a
> discussion about the 64-bit syscall interface started.  It's still not
> cast into stone so we can modify it as we see fit.  The entire syscall
> interface is still open for changes, this includes all structures etc.
> Along with a 64-bit ABI we'll also have to deciede about a N32 ABI.
> 
> Suggestions, comments etc?

  Ralf

  parent reply	other threads:[~2002-09-16 13:02 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-04 13:56 64-bit and N32 kernel interfaces Ralf Baechle
2002-09-04 14:14 ` Maciej W. Rozycki
2002-09-04 14:31   ` Ralf Baechle
2002-09-04 15:19     ` Maciej W. Rozycki
2002-09-04 18:46       ` Ralf Baechle
2002-09-05  9:53         ` Maciej W. Rozycki
2002-09-05  6:40       ` Carsten Langgaard
2002-09-05  9:23         ` Maciej W. Rozycki
2002-09-05 13:41           ` Daniel Jacobowitz
2002-09-04 17:32     ` Jun Sun
2002-09-04 17:56       ` Maciej W. Rozycki
2002-09-04 18:40       ` Ralf Baechle
2002-09-05 10:15         ` Kjeld Borch Egevang
2002-09-05 10:15           ` Kjeld Borch Egevang
2002-09-09 20:20 ` Jay Carlson
2002-09-16 13:01 ` Ralf Baechle [this message]
2002-09-16 15:40   ` Ralf Baechle
  -- strict thread matches above, loose matches on Subject: below --
2002-09-05  9:30 Tor Arntsen
2002-09-05 11:47 ` Maciej W. Rozycki
2002-09-05 12:48   ` Kevin D. Kissell
2002-09-05 12:48     ` Kevin D. Kissell
2002-09-05 14:09     ` Maciej W. Rozycki
2002-09-05 14:20       ` Hartvig Ekner
2002-09-05 14:20         ` Hartvig Ekner
2002-09-05 14:54         ` Maciej W. Rozycki
2002-09-05 14:59           ` Daniel Jacobowitz
2002-09-05 15:10             ` Maciej W. Rozycki
2002-09-05 15:14               ` Daniel Jacobowitz
2002-09-05 16:16                 ` Maciej W. Rozycki
2002-09-05 16:19                   ` Daniel Jacobowitz
2002-09-05 16:33                     ` Maciej W. Rozycki
2002-09-05 16:39                       ` Daniel Jacobowitz
2002-09-05 17:16                         ` Maciej W. Rozycki
2002-09-05 17:29                   ` Kevin D. Kissell
2002-09-05 17:29                     ` Kevin D. Kissell
2002-09-05 19:34                     ` Maciej W. Rozycki
2002-09-06  9:42                   ` Ralf Baechle
2002-09-05 18:07               ` Hartvig Ekner
2002-09-05 18:07                 ` Hartvig Ekner
2002-09-05 18:54                 ` Maciej W. Rozycki
2002-09-05 19:16                   ` Thiemo Seufer
2002-09-06  9:30               ` Ralf Baechle
2002-09-05 14:22       ` Daniel Jacobowitz
2002-09-05 15:08         ` Maciej W. Rozycki
2002-09-05 15:14           ` Daniel Jacobowitz
2002-09-05 16:28             ` Maciej W. Rozycki
2002-09-05 16:30           ` Thiemo Seufer
2002-09-05 16:54             ` Maciej W. Rozycki
2002-09-05 17:44               ` Thiemo Seufer
2002-09-05 19:50                 ` Maciej W. Rozycki
2002-09-05 22:12                   ` Thiemo Seufer
2002-09-09 17:39                     ` Maciej W. Rozycki
2002-09-06 10:14           ` Ralf Baechle
2002-09-09 14:01             ` Dominic Sweetman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020916150152.A1677@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=linux-mips@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.