[PATCH] Complain about missing system calls.

Most system calls seem to get added to i386 first. This patch
automatically generates a warning for any new system call which is
implemented on i386 but not the architecture currently being compiled.
On PowerPC at the moment, for example, it results in these warnings:
init/missing_syscalls.h:935:3: warning: #warning syscall sync_file_range not implemented
init/missing_syscalls.h:947:3: warning: #warning syscall getcpu not implemented
init/missing_syscalls.h:950:3: warning: #warning syscall epoll_pwait not implemented

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

index 0154aea..826433b 100644

--- a/init/Makefile
+++ b/init/Makefile

@@ -2,7 +2,7 @@
 # Makefile for the linux kernel.
 #
 
-obj-y                          := main.o version.o mounts.o
+obj-y                          := main.o version.o mounts.o missing_syscalls.o
 ifneq ($(CONFIG_BLK_DEV_INITRD),y)
 obj-y                          += noinitramfs.o
 else

@@ -16,11 +16,12 @@ mounts-$(CONFIG_BLK_DEV_INITRD)	+= do_mounts_initrd.o
 mounts-$(CONFIG_BLK_DEV_MD)	+= do_mounts_md.o
 
 # files to be removed upon make clean
-clean-files := ../include/linux/compile.h
+clean-files := ../include/linux/compile.h $(obj)/missing_syscalls.h
 
 # dependencies on generated files need to be listed explicitly
 
 $(obj)/version.o: include/linux/compile.h
+$(obj)/missing_syscalls.o: $(obj)/missing_syscalls.h include/linux/compile.h FORCE
 
 # compile.h changes depending on hostname, generation number, etc,
 # so we regenerate it always.

@@ -31,3 +32,13 @@ include/linux/compile.h: FORCE
 	@echo '  CHK     $@'
 	$(Q)$(CONFIG_SHELL) $(srctree)/scripts/mkcompile_h $@ \
 	"$(UTS_MACHINE)" "$(CONFIG_SMP)" "$(CONFIG_PREEMPT)" "$(CC) $(CFLAGS)"
+
+
+quiet_cmd_missing_syscalls = GEN     $@
+      cmd_missing_syscalls = sed -n '/^\#define/s/[^_]*__NR_\([^[:space:]]*\).*/\
+	\#if !defined (__NR_\1) \&\& !defined (__IGNORE_\1)\n\
+	\#warning syscall \1 not implemented\n\
+	\#endif/p' $(srctree)/include/asm-i386/unistd.h >$@
+targets += missing_syscalls.h
+$(obj)/missing_syscalls.h: include/asm-i386/unistd.h
+	$(call if_changed,missing_syscalls)
--- /dev/null	2007-03-08 11:51:40.542628703 +0000
+++ b/init/missing_syscalls.c	2007-03-08 22:48:27.000000000 +0000

@@ -0,0 +1,57 @@
+#include <asm/types.h>
+#include <asm/unistd.h>
+
+/* Force recompilation (and thus warnings) every time we rebuild the kernel */
+#include <linux/compile.h>
+
+/* System calls for 32-bit kernels only */
+#if BITS_PER_LONG == 64
+#define __IGNORE_sendfile64
+#define __IGNORE_ftruncate64
+#define __IGNORE_truncate64
+#define __IGNORE_stat64
+#define __IGNORE_lstat64
+#define __IGNORE_fstat64
+#define __IGNORE_fcntl64
+#define __IGNORE_fadvise64_64
+#define __IGNORE_fstatat64
+#endif
+
+/* i386-specific or historical system calls */
+#define __IGNORE_mmap2
+#define __IGNORE_vm86
+#define __IGNORE_vm86old
+#define __IGNORE_set_thread_area
+#define __IGNORE_get_thread_area
+#define __IGNORE_madvise1
+#define __IGNORE_oldstat
+#define __IGNORE_oldfstat
+#define __IGNORE_oldlstat
+#define __IGNORE_oldolduname
+#define __IGNORE_olduname
+#define __IGNORE_umount2
+/* ... including the "new" 32-bit uid syscalls */
+#define __IGNORE_lchown32
+#define __IGNORE_getuid32
+#define __IGNORE_getgid32
+#define __IGNORE_geteuid32
+#define __IGNORE_getegid32
+#define __IGNORE_setreuid32
+#define __IGNORE_setregid32
+#define __IGNORE_getgroups32
+#define __IGNORE_setgroups32
+#define __IGNORE_fchown32
+#define __IGNORE_setresuid32
+#define __IGNORE_getresuid32
+#define __IGNORE_setresgid32
+#define __IGNORE_getresgid32
+#define __IGNORE_chown32
+#define __IGNORE_setuid32
+#define __IGNORE_setgid32
+#define __IGNORE_setfsuid32
+#define __IGNORE_setfsgid32
+
+/* Not yet upstream */
+#define __IGNORE_vserver
+
+#include "missing_syscalls.h"

-- 
dwmw2

From: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 08 Mar 2007 23:01:13 +0000

Most system calls seem to get added to i386 first. This patch
automatically generates a warning for any new system call which is
implemented on i386 but not the architecture currently being compiled.
On PowerPC at the moment, for example, it results in these warnings:
init/missing_syscalls.h:935:3: warning: #warning syscall sync_file_range not implemented
init/missing_syscalls.h:947:3: warning: #warning syscall getcpu not implemented
init/missing_syscalls.h:950:3: warning: #warning syscall epoll_pwait not implemented

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

David, thanks for this __incredibly__ __useful__ patch.  I kicked it
around on sparc64 and found some more ignores to add, see below.

The vast majority of them vector to sys_ni_syscall in the i386 syscall
table.

sys_ugetrlimit is only necessary if the platform started out
using the non-SuS compliant sys_old_getrlimit()

The rest, like ioperm, iopl, modify_ldt, et al. are i386
specific.

Signed-off-by: David S. Miller <davem@davemloft.net>

--- a/init/missing_syscalls.c.ORIG	2007-03-08 16:11:00.000000000 -0800
+++ b/init/missing_syscalls.c	2007-03-08 16:02:30.000000000 -0800

@@ -18,6 +18,22 @@
 #endif
 
 /* i386-specific or historical system calls */
+#define __IGNORE_break
+#define __IGNORE_stty
+#define __IGNORE_gtty
+#define __IGNORE_ftime
+#define __IGNORE_prof
+#define __IGNORE_lock
+#define __IGNORE_mpx
+#define __IGNORE_ulimit
+#define __IGNORE_profil
+#define __IGNORE_ioperm
+#define __IGNORE_iopl
+#define __IGNORE_idle
+#define __IGNORE_modify_ldt
+#define __IGNORE_getpmsg
+#define __IGNORE_putpmsg
+#define __IGNORE_ugetrlimit
 #define __IGNORE_mmap2
 #define __IGNORE_vm86
 #define __IGNORE_vm86old

On Thu, 2007-03-08 at 16:14 -0800, David Miller wrote:

The rest, like ioperm, iopl, modify_ldt, et al. are i386
specific.

Thanks for the update. Quite why the PowerPC kernel defines system call
numbers for all of these I have no idea :)

-- 
dwmw2

Hi,

Most system calls seem to get added to i386 first. This patch
automatically generates a warning for any new system call which is
implemented on i386 but not the architecture currently being compiled.
On PowerPC at the moment, for example, it results in these warnings:

Love it!

...

Thanks for the update. Quite why the PowerPC kernel defines system
call numbers for all of these I have no idea :)

BTW while unistd.h may refer to sys_iopl etc, the actual syscall is sent
to ni_syscall in most of these useless cases.

Anton

On Thu, Mar 08, 2007 at 11:01:13PM +0000, David Woodhouse wrote:

Most system calls seem to get added to i386 first. This patch
automatically generates a warning for any new system call which is
implemented on i386 but not the architecture currently being compiled.
On PowerPC at the moment, for example, it results in these warnings:
init/missing_syscalls.h:935:3: warning: #warning syscall sync_file_range not implemented
init/missing_syscalls.h:947:3: warning: #warning syscall getcpu not implemented
init/missing_syscalls.h:950:3: warning: #warning syscall epoll_pwait not implemented

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

You might also like to add:

Signed-off-by: Russell King <redacted>

since I did resolve the issues with getting a sed expression which
did the right thing, rather than your for loop, awk, echo, and
providing a way to ignore the lack of certain syscall numbers...

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

David Woodhouse [off-list ref] writes:

Most system calls seem to get added to i386 first. This patch
automatically generates a warning for any new system call which is
implemented on i386 but not the architecture currently being compiled.
On PowerPC at the moment, for example, it results in these warnings:
init/missing_syscalls.h:935:3: warning: #warning syscall sync_file_range not implemented
init/missing_syscalls.h:947:3: warning: #warning syscall getcpu not implemented
init/missing_syscalls.h:950:3: warning: #warning syscall epoll_pwait not implemented

I think a better solution would be to finally switch to auto generated
system call tables for newer system calls. The original reason why the
architectures have different system call numbers -- compatibility with
another "native" Unix -- is completely obsolete now. This leaves only
minor differences of compat stub vs non compat stub and a few
architecture specific calls.

Of course the existing syscall numbers can't be changed, but for all new 
calls one could just add automatically for everybody.

A global table with two entries (compat and non compat) and a per arch 
override table should be sufficient.

Comments?

-Andi

On Fri, 2007-03-09 17:11:10 +0100, Andi Kleen [off-list ref] wrote:

David Woodhouse [off-list ref] writes:

quoted

Most system calls seem to get added to i386 first. This patch
automatically generates a warning for any new system call which is
implemented on i386 but not the architecture currently being compiled.
On PowerPC at the moment, for example, it results in these warnings:
init/missing_syscalls.h:935:3: warning: #warning syscall sync_file_range not implemented
init/missing_syscalls.h:947:3: warning: #warning syscall getcpu not implemented
init/missing_syscalls.h:950:3: warning: #warning syscall epoll_pwait not implemented

I think a better solution would be to finally switch to auto generated
system call tables for newer system calls. The original reason why the
architectures have different system call numbers -- compatibility with
another "native" Unix -- is completely obsolete now. This leaves only
minor differences of compat stub vs non compat stub and a few
architecture specific calls.

Of course the existing syscall numbers can't be changed, but for all new 
calls one could just add automatically for everybody.

A global table with two entries (compat and non compat) and a per arch 
override table should be sufficient.

Not everybody has a simple indexed list of pointers :)  For example,
for vax-linux, we use a struct per syscall with the expected number of
on-stack longwords for the call.

So if something "new" is coming up, please keep in mind that it should
be flexible enough to represent that. :)

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:         "really soon now":      an unspecified period of time, likly to
the second  :                                 be greater than any reasonable definition
                                              of "soon".

On Fri, 2007-03-09 at 17:11 +0100, Andi Kleen wrote:

David Woodhouse [off-list ref] writes:

quoted

Most system calls seem to get added to i386 first. This patch
automatically generates a warning for any new system call which is
implemented on i386 but not the architecture currently being compiled.
On PowerPC at the moment, for example, it results in these warnings:
init/missing_syscalls.h:935:3: warning: #warning syscall sync_file_range not implemented
init/missing_syscalls.h:947:3: warning: #warning syscall getcpu not implemented
init/missing_syscalls.h:950:3: warning: #warning syscall epoll_pwait not implemented

I think a better solution would be to finally switch to auto generated
system call tables for newer system calls. The original reason why the
architectures have different system call numbers -- compatibility with
another "native" Unix -- is completely obsolete now. This leaves only
minor differences of compat stub vs non compat stub and a few
architecture specific calls.

Of course the existing syscall numbers can't be changed, but for all new 
calls one could just add automatically for everybody.

A global table with two entries (compat and non compat) and a per arch 
override table should be sufficient.

We need additional gunk for syscalls that can be called from SPEs on
cell

Ben.

On Fri, 2007-03-09 at 17:11 +0100, Andi Kleen wrote:

Of course the existing syscall numbers can't be changed, but for all new 
calls one could just add automatically for everybody.

A global table with two entries (compat and non compat) and a per arch 
override table should be sufficient.

Counterexample: sys_epoll_pwait.

It'd be nice if it were that simple.

It'd also be nice if people stopped thinking it was that simple :)

-- 
dwmw2

We need additional gunk for syscalls that can be called from SPEs on
cell

Can that gunk not be auto generated?

I know s390 does in some cases, but it looks quite auto generatable to me.

-Andi

Not everybody has a simple indexed list of pointers :)  For example,
for vax-linux, we use a struct per syscall with the expected number of
on-stack longwords for the call.

So if something "new" is coming up, please keep in mind that it should
be flexible enough to represent that. :)

Are there plans to merge vax any time soon to mainline? 

Normally we don't care very much about out of tree code, especially
if it adds complexity like this.

But I suspect s390 would need number of arguments anyways.

-Andi

On Fri, 2007-03-09 20:00:51 +0100, Andi Kleen [off-list ref] wrote:

quoted

Not everybody has a simple indexed list of pointers :)  For example,
for vax-linux, we use a struct per syscall with the expected number of
on-stack longwords for the call.

So if something "new" is coming up, please keep in mind that it should
be flexible enough to represent that. :)

Are there plans to merge vax any time soon to mainline? 

Well...  That depends :)  For now, I'd prefer to stay out of mainline,
until we're having gcc-trunk with a current GNU libc up'n'running.
Until then, I plan to at least break the complete ABI once (drop old
syscals and _only_ wire up their modern counterparts.)

Normally we don't care very much about out of tree code, especially
if it adds complexity like this.

Sure, but at least mentioning that there's more than only a simple
table of function pointers may or may not help to *plan* the code to
fit future needs.

But I suspect s390 would need number of arguments anyways.

Any they're already merged. Yay :)

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
  Signature of:                           Wenn ich wach bin, träume ich.
  the second  :

Jan-Benedict Glaw wrote:

Not everybody has a simple indexed list of pointers :)  For example,
for vax-linux, we use a struct per syscall with the expected number of
on-stack longwords for the call.

So if something "new" is coming up, please keep in mind that it should
be flexible enough to represent that. :)

I discussed with Al Viro a while ago about using something like the 
SYSCALLS.def file from klibc as the source format for the system calls. 
  That would deal very flexibly with almost all kinds of stub generation.

	-hpa

On Fri, Mar 09, 2007 at 11:40:08AM -0800, H. Peter Anvin wrote:

Jan-Benedict Glaw wrote:

quoted

Not everybody has a simple indexed list of pointers :)  For example,
for vax-linux, we use a struct per syscall with the expected number of
on-stack longwords for the call.

So if something "new" is coming up, please keep in mind that it should
be flexible enough to represent that. :)

I discussed with Al Viro a while ago about using something like the 
SYSCALLS.def file from klibc as the source format for the system calls. 
 That would deal very flexibly with almost all kinds of stub generation.

Hopefully with this idea in place, we can spot new syscalls before
the final release of the kernel (maybe kautobuild can help there)
and fix any silly system call argument ordering which requires
different architectures to have different syscall prototypes (eg,
sys_arm_fadvise64_64 vs sys_fadvise64_64, sys_arm_sync_file_range vs
sys_sync_file_range).

Otherwise the SYSCALLS.def file will probably end up being full of
ifdefs.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Russell King wrote:

On Fri, Mar 09, 2007 at 11:40:08AM -0800, H. Peter Anvin wrote:

quoted

Jan-Benedict Glaw wrote:

quoted

Not everybody has a simple indexed list of pointers :)  For example,
for vax-linux, we use a struct per syscall with the expected number of
on-stack longwords for the call.

So if something "new" is coming up, please keep in mind that it should
be flexible enough to represent that. :)

I discussed with Al Viro a while ago about using something like the 
SYSCALLS.def file from klibc as the source format for the system calls. 
 That would deal very flexibly with almost all kinds of stub generation.

Hopefully with this idea in place, we can spot new syscalls before
the final release of the kernel (maybe kautobuild can help there)
and fix any silly system call argument ordering which requires
different architectures to have different syscall prototypes (eg,
sys_arm_fadvise64_64 vs sys_fadvise64_64, sys_arm_sync_file_range vs
sys_sync_file_range).

That would definitely be nice.

Otherwise the SYSCALLS.def file will probably end up being full of
ifdefs.

... which exactly mirrors the pain and suffering which libc maintainers 
have to deal with.  The amount of time I spent per line of code in klibc 
is quite high, in part because I wanted it to be as self-porting as was 
possible.  I've really tried to avoid arch-specific hacks, and yet there 
are more there than there should be, in large part because of unusable 
or missing kernel header exports.

	-hpa

On Fri, 2007-03-09 at 19:54 +0100, Andi Kleen wrote:

quoted

We need additional gunk for syscalls that can be called from SPEs on
cell

Can that gunk not be auto generated?

I know s390 does in some cases, but it looks quite auto generatable to me.

The system call tables and the compat wrapper are all manually created.
If we manage to get the prototypes for the system calls in a parseable
format at least the compat wrappers could be auto-generated. I see two
pitfalls: 1) some compat system calls are directly wired to the system
call table while others need the compat_wrapper detour, 2) override of
system calls with "meta" system calls like sys_socket or sys_ipc.

-- 
blue skies,              IBM Deutschland Entwicklung GmbH
   Martin                Vorsitzender des Aufsichtsrats: Johann Weihen
                         Geschäftsführung: Herbert Kircher
Martin Schwidefsky       Sitz der Gesellschaft: Böblingen
Linux on zSeries         Registergericht: Amtsgericht Stuttgart,
   Development           HRB 243294

"Reality continues to ruin my life." - Calvin.

On Fri, 2007-03-09 at 20:00 +0100, Andi Kleen wrote:

quoted

Not everybody has a simple indexed list of pointers :)  For example,
for vax-linux, we use a struct per syscall with the expected number of
on-stack longwords for the call.

So if something "new" is coming up, please keep in mind that it should
be flexible enough to represent that. :)

Are there plans to merge vax any time soon to mainline? 

Normally we don't care very much about out of tree code, especially
if it adds complexity like this.

But I suspect s390 would need number of arguments anyways.

I can't quite follow that line of thought. Why does s390 need the number
of arguments? The wrapper of a compat system call implicitly knows how
many arguments a system calls to do the conversion. For a normal system
call we just call the function. Random example sys_read: the user space
loads the arguments to register %r2, %r3, %r4 and calls the system. The
register are not touched until sys_read is reached. Only sys_read cares
about the number of arguments in this case.

-- 
blue skies,              IBM Deutschland Entwicklung GmbH
   Martin                Vorsitzender des Aufsichtsrats: Johann Weihen
                         Geschäftsführung: Herbert Kircher
Martin Schwidefsky       Sitz der Gesellschaft: Böblingen
Linux on zSeries         Registergericht: Amtsgericht Stuttgart,
   Development           HRB 243294

"Reality continues to ruin my life." - Calvin.

On Thu, 08 Mar 2007 23:01:13 +0000
David Woodhouse [off-list ref] wrote:

Most system calls seem to get added to i386 first. This patch
automatically generates a warning for any new system call which is
implemented on i386 but not the architecture currently being compiled.
On PowerPC at the moment, for example, it results in these warnings:
init/missing_syscalls.h:935:3: warning: #warning syscall sync_file_range not implemented
init/missing_syscalls.h:947:3: warning: #warning syscall getcpu not implemented
init/missing_syscalls.h:950:3: warning: #warning syscall epoll_pwait not implemented

hm, did you try running this on x86_64?

In file included from init/missing_syscalls.c:73:
init/missing_syscalls.h:23:3: warning: #warning syscall waitpid not implemented
init/missing_syscalls.h:68:3: warning: #warning syscall umount not implemented
init/missing_syscalls.h:77:3: warning: #warning syscall stime not implemented
init/missing_syscalls.h:104:3: warning: #warning syscall nice not implemented
init/missing_syscalls.h:146:3: warning: #warning syscall signal not implemented
init/missing_syscalls.h:203:3: warning: #warning syscall sigaction not implemented
init/missing_syscalls.h:206:3: warning: #warning syscall sgetmask not implemented
init/missing_syscalls.h:209:3: warning: #warning syscall ssetmask not implemented
init/missing_syscalls.h:218:3: warning: #warning syscall sigsuspend not implemented
init/missing_syscalls.h:221:3: warning: #warning syscall sigpending not implemented
init/missing_syscalls.h:269:3: warning: #warning syscall readdir not implemented
init/missing_syscalls.h:308:3: warning: #warning syscall socketcall not implemented
init/missing_syscalls.h:353:3: warning: #warning syscall ipc not implemented
init/missing_syscalls.h:359:3: warning: #warning syscall sigreturn not implemented
init/missing_syscalls.h:380:3: warning: #warning syscall sigprocmask not implemented
init/missing_syscalls.h:404:3: warning: #warning syscall bdflush not implemented
init/missing_syscalls.h:422:3: warning: #warning syscall _llseek not implemented
init/missing_syscalls.h:428:3: warning: #warning syscall _newselect not implemented
init/missing_syscalls.h:800:3: warning: #warning syscall statfs64 not implemented
init/missing_syscalls.h:803:3: warning: #warning syscall fstatfs64 not implemented
init/missing_syscalls.h:947:3: warning: #warning syscall getcpu not implemented
init/missing_syscalls.h:950:3: warning: #warning syscall epoll_pwait not implemented
init/missing_syscalls.h:953:3: warning: #warning syscall lutimesat not implemented
init/missing_syscalls.h:956:3: warning: #warning syscall revokeat not implemented
init/missing_syscalls.h:959:3: warning: #warning syscall frevoke not implemented

On Mon, 2007-03-19 at 16:42 -0700, Andrew Morton wrote:

hm, did you try running this on x86_64?

I don't have any. I only tested it on PowerPC and i386. Others then
provided more exclusions for SPARC and maybe ARM, although I'm not sure
you have the latter yet. It's not hard to add extra exclusions.

-- 
dwmw2

David Woodhouse [off-list ref] wrote:

quoted

hm, did you try running this on x86_64?

I don't have any. I only tested it on PowerPC and i386. Others then
provided more exclusions for SPARC and maybe ARM, although I'm not sure
you have the latter yet. It's not hard to add extra exclusions.

You could always have asked to borrow my test box.

David

On Tue, Mar 20, 2007 at 07:43:08AM +0000, David Woodhouse wrote:

On Mon, 2007-03-19 at 16:42 -0700, Andrew Morton wrote:

quoted

hm, did you try running this on x86_64?

I don't have any. I only tested it on PowerPC and i386. Others then
provided more exclusions for SPARC and maybe ARM, although I'm not sure
you have the latter yet. It's not hard to add extra exclusions.

Some of the ones which come up on x86_64 also come up on ARM for the
same reason; they're obsolete system calls which probably shouldn't
be implemented on anything but legacy i386.  Things like waitpid, etc.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

On Thu, Mar 08, 2007 at 04:14:07PM -0800, David Miller wrote:

Could it make sense to keep this in arch specific header files?
So when we fiddle with ARM we do not impact SPARC etc.
And in this way ARCH specific changes are kept in ARCH specific files.

For the "Ignore historical" part this should be in a common file I think.

So in other words:

init/missing_syscalls.h	=> Contains common stuff and include:
include/asm/missing_syscalls.h => contains ARCH specific stuff.


	Sam

On Mon, 2007-03-19 at 16:42 -0700, Andrew Morton wrote:

hm, did you try running this on x86_64?

git://git.infradead.org/~dwmw2/syscalls-2.6.git

Should make it quieter on ARM and x86_64, and includes Stéphane's patch
to make it work with dash.

-- 
dwmw2