On Mon, 17 Feb 2020 23:35:36 +0100 Laurent Vivier <laur...@vivier.eu> 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?
