[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Cornelia Huck
Subject: Re: [PATCH 00/22] linux-user: generate syscall_nr.sh
Date: Tue, 18 Feb 2020 15:27:48 +0100

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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]