On Tuesday, February 18, 2020, Cornelia Huck <coh...@redhat.com> wrote:
> On Tue, 18 Feb 2020 16:19:21 +0100 > Laurent Vivier <laur...@vivier.eu> wrote: > > > Le 18/02/2020 à 15:27, Cornelia Huck a écrit : > > > 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? > > > > I think it's a good idea to update the syscall.tbl when we update > > linux-headers, and there will be no change at linux-user level while we > > don't implement the syscall translation in syscall.c:do_syscall1(). > > Nod. > > > > > But I think we should also check manually the difference between new and > > old generated syscall_nr.h to be sure there is nothing broken in what we > > introduce. > > > > I always run a Linux Test Project testsuite for all architectures with a > > debian distro when I do a pull request so I can detect regression. > > > > In the end, updating linux-headers should trigger syscall.tbl update but > > it needs manual inspection. > > I think we should make sure that updating syscall.tbl does not get > forgotten if we do a headers update... have the update script print out > a message? I'm not sure if we want to automate updating the syscall > table, as we want manual inspection for it. > > Maybe have the update script moan about syscall.tbl if unistd.h is > changed? Should be a good enough heuristic. > > That said, I'll probably queue a headers update on the s390-next branch > right now (against current Linus master), > Hi, Cornelia, I am not stopping you from updating headers from Linus' master, however, I think a better practice would be to do regular updates from each stable kernel release (the last one is 5.5), rather than from an arbitrary kernel-du-jour, which may be the subject of change (including reverts) wrt headers between two stable releases. Regards, Aleksandar > > unless someone complains -- > maybe take the syscall.tbl from that state of the kernel tree as well? > > >
