From: Wieland Gmeiner <e8607062@student.tuwien.ac.at>
To: linux-kernel <linux-kernel@vger.kernel.org>
Cc: Wieland Gmeiner <e8607062@student.tuwien.ac.at>
Subject: System call registration mess?
Date: Wed, 13 Jul 2005 03:18:32 +0200 [thread overview]
Message-ID: <1121217512.17472.93.camel@w2> (raw)
I want to register a new system call and notice that on several
architectures there is some inconsistency between the system call table
and unistd.h, e.g. (2.6.13-rc2):
in arch/arm/kernel/calls.S:
...
/* 310 */ .long sys_request_key
.long sys_keyctl
.long sys_semtimedop
__syscall_end:
...
and in include/asm-arm/unistd.h:
...
#define __NR_request_key (__NR_SYSCALL_BASE+310)
#define __NR_keyctl (__NR_SYSCALL_BASE+311)
#if 0 /* reserved for un-muxing ipc */
#define __NR_semtimedop (__NR_SYSCALL_BASE+312)
#endif
#define __NR_vserver (__NR_SYSCALL_BASE+313)
/*
* The following SWIs are ARM private.
*/
#define __ARM_NR_BASE (__NR_SYSCALL_BASE+0x0f0000)
...
So it seems that sys_vserver is not declared in the system call table.
Is there any reason for this inconsistency or is this a bug and should
be fixed? If second, should there be something like
.long sys_ni_syscall /* reserved for vserver */
or
.long sys_vserver
in the syscall table?
Similar inconsistencies can be found in other architecture subtrees,
e.g. in arm26:
arch/arm26/kernel/calls.S:
...
/* 235 */ .long sys_removexattr
.long sys_lremovexattr
.long sys_fremovexattr
.long sys_tkill
__syscall_end:
...
in include/asm-arm26/unistd.h there is a whole bunch of calls that are
not registered in the system call table:
#define __NR_tkill (__NR_SYSCALL_BASE+238)
#define __NR_sendfile64 (__NR_SYSCALL_BASE+239)
#define __NR_futex (__NR_SYSCALL_BASE+240)
...
#define __NR_mq_notify (__NR_SYSCALL_BASE+278)
#define __NR_mq_getsetattr (__NR_SYSCALL_BASE+279)
#define __NR_waitid (__NR_SYSCALL_BASE+280)
Should they all get filled up with sys_ni_syscall definitions or with
their corresponding entries so I can enter my own syscall at the bottom
with correct numbering or what is the proper way to register a new
syscall in these cases?
Thanks,
Wieland
reply other threads:[~2005-07-13 1:18 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1121217512.17472.93.camel@w2 \
--to=e8607062@student.tuwien.ac.at \
--cc=linux-kernel@vger.kernel.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.