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 17:40:52 +0200 [thread overview]
Message-ID: <20020916174052.B2579@linux-mips.org> (raw)
In-Reply-To: <20020916150152.A1677@linux-mips.org>; from ralf@linux-mips.org on Mon, Sep 16, 2002 at 03:01:52PM +0200
On Mon, Sep 16, 2002 at 03:01:52PM +0200, Ralf Baechle wrote:
More chainswing ...
> > 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.
llseek, pread64/pwrite64, getdent64 are no longer needed as their standard
counterparts are already 64 bit.
Modern libc doesn't use the old style signal calls __NR_sigaction,
__NR_sigsuspend, __NR_sigpending, __NR_sigprocmask. That means
__NR_sigreturn can also go.
__NR_sgetmask and __NR_ssetmask are only capable of dealing with signal masks
of at most bitsof(long) and thus have become useless and replaced by
sigprocmask(2).
__NR_waitpid can be implemented on top of wait(2).
__NR_stime can be implemented on top of settimeofday(2).
__NR_nice can be implemented on top of getpriority / setpriority and was
a stupid interface anyway.
__NR_recv can be implemented on recvfrom(2) and __NR_send using sendfrom(2).
Ralf
next prev parent reply other threads:[~2002-09-16 15:41 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
2002-09-16 15:40 ` Ralf Baechle [this message]
-- 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=20020916174052.B2579@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.