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

[Aleksandar Markovic <aleksandar.m.mail@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3697 bytes --]

On Tuesday, February 18, 2020, Cornelia Huck <cohuck@redhat.com> wrote:

> On Tue, 18 Feb 2020 16:19:21 +0100
> Laurent Vivier <laurent@vivier.eu> wrote:
>
> > Le 18/02/2020 à 15:27, Cornelia Huck a écrit :
> > > On Mon, 17 Feb 2020 23:35:36 +0100
> > > Laurent Vivier <laurent@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?
>
>
>

[-- Attachment #2: Type: text/html, Size: 4895 bytes --]