Re: [PATCH 00/22] linux-user: generate syscall_nr.sh

[Cornelia Huck]

On Mon, 17 Feb 2020 23:35:36 +0100
Laurent Vivier <address@hidden> wrote:

> This series copies the files syscall.tbl from linux v5.5 and generates
> the file syscall_nr.h from them.
> 
> This is done for all the QEMU targets that have a syscall.tbl
> in the linux source tree: mips, mips64, i386, x86_64, sparc, s390x,
> ppc, arm, microblaze, sh4, xtensa, m68k, hppa and alpha.
> 
> tilegx and cris are depecrated in linux (tilegx has no maintainer in QEMU)
> 
> aarch64, nios2, openrisc and riscv have no syscall.tbl in linux.
> 
> It seems there is a bug in QEMU that forces to disable manually arch_prctl
> with i386 target: do_arch_prctl() is only defined with TARGET_ABI32 but
> TARGET_ABI32 is never defined with TARGET_I386 (nor TARGET_X86_64).
> 
> I have also removed all syscalls in s390x/syscall_nr.h defined for
> !defined(TARGET_S390X).
> 
> I have added a script to copy all these files from linux and updated
> them at the end of the series with their latest version for today.
> 
> The two last patches manage the special case for mips O32 that needs
> to know the number of arguments. We find them in strace sources.

I like the idea of generating those files, but I wonder if that should
interact with linux-headers updates.

I plan to do a linux-headers update to 5.6-rc?, and I noticed that this
will drag in two new syscalls (openat2 and pidfd_getfd). Now, just
having the new #defines in the headers doesn't do anything, but should
it be a trigger to update the syscall.tbl files as well? Or does that
need manual inspection/updating?