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

[Cornelia Huck]

On Tue, 18 Feb 2020 16:19:21 +0100
Laurent Vivier <address@hidden> wrote:

> Le 18/02/2020 à 15:27, Cornelia Huck a écrit :
> > 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?  
> 
> 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), unless someone complains --
maybe take the syscall.tbl from that state of the kernel tree as well?