| Message ID | 20200217223558.863199-1-laurent@vivier.eu (mailing list archive) |
|---|---|
| Headers | show |
| Series | linux-user: generate syscall_nr.sh | expand |
On 2/17/20 11:35 PM, Laurent Vivier wrote: > This series copies the files syscall.tbl from linux v5.5 and generates > the file syscall_nr.h from them. > [...] > Laurent Vivier (22): > linux-user: introduce parameters to generate syscall_nr.h > linux-user,alpha: add syscall table generation support > linux-user,hppa: add syscall table generation support > linux-user,m68k: add syscall table generation support > linux-user,xtensa: add syscall table generation support > linux-user,sh4: add syscall table generation support > linux-user,microblaze: add syscall table generation support > linux-user,arm: add syscall table generation support > linux-user,ppc: split syscall_nr.h > linux-user,ppc: add syscall table generation support > linux-user,s390x: remove syscall definitions for !TARGET_S390X > linux-user,s390x: add syscall table generation support > linux-user,sparc,sparc64: add syscall table generation support > linux-user,i386: add syscall table generation support > linux-user,x86_64: add syscall table generation support > linux-user,mips: add syscall table generation support > linux-user,mips64: split syscall_nr.h > linux-user,mips64: add syscall table generation support > linux-user,scripts: add a script to update syscall.tbl > linux-user: update syscall.tbl from linux 0bf999f9c5e7 > linux-user,mips: move content of mips_syscall_args > linux-user,mips: update syscall-args-o32.c.inc I suppose the patch subject was generated and you meant to use "linux-user/" instead of "linux-user,". Is that right?
Le 18/02/2020 à 07:13, Philippe Mathieu-Daudé a écrit : > On 2/17/20 11:35 PM, Laurent Vivier wrote: >> This series copies the files syscall.tbl from linux v5.5 and generates >> the file syscall_nr.h from them. >> > [...] >> Laurent Vivier (22): >> linux-user: introduce parameters to generate syscall_nr.h >> linux-user,alpha: add syscall table generation support >> linux-user,hppa: add syscall table generation support >> linux-user,m68k: add syscall table generation support >> linux-user,xtensa: add syscall table generation support >> linux-user,sh4: add syscall table generation support >> linux-user,microblaze: add syscall table generation support >> linux-user,arm: add syscall table generation support >> linux-user,ppc: split syscall_nr.h >> linux-user,ppc: add syscall table generation support >> linux-user,s390x: remove syscall definitions for !TARGET_S390X >> linux-user,s390x: add syscall table generation support >> linux-user,sparc,sparc64: add syscall table generation support >> linux-user,i386: add syscall table generation support >> linux-user,x86_64: add syscall table generation support >> linux-user,mips: add syscall table generation support >> linux-user,mips64: split syscall_nr.h >> linux-user,mips64: add syscall table generation support >> linux-user,scripts: add a script to update syscall.tbl >> linux-user: update syscall.tbl from linux 0bf999f9c5e7 >> linux-user,mips: move content of mips_syscall_args >> linux-user,mips: update syscall-args-o32.c.inc > > I suppose the patch subject was generated and you meant to use > "linux-user/" instead of "linux-user,". Is that right? > No, the idea is they touch "linux-user" subsystem and "ARCH" subsystem, not especially the "linux-user/ARCH" directory Thanks, Laurent
On Tuesday, February 18, 2020, Laurent Vivier <laurent@vivier.eu> wrote: > Le 18/02/2020 à 07:13, Philippe Mathieu-Daudé a écrit : > > On 2/17/20 11:35 PM, Laurent Vivier wrote: > >> This series copies the files syscall.tbl from linux v5.5 and generates > >> the file syscall_nr.h from them. > >> > > [...] > >> Laurent Vivier (22): > >> linux-user: introduce parameters to generate syscall_nr.h > >> linux-user,alpha: add syscall table generation support > >> linux-user,hppa: add syscall table generation support > >> linux-user,m68k: add syscall table generation support > >> linux-user,xtensa: add syscall table generation support > >> linux-user,sh4: add syscall table generation support > >> linux-user,microblaze: add syscall table generation support > >> linux-user,arm: add syscall table generation support > >> linux-user,ppc: split syscall_nr.h > >> linux-user,ppc: add syscall table generation support > >> linux-user,s390x: remove syscall definitions for !TARGET_S390X > >> linux-user,s390x: add syscall table generation support > >> linux-user,sparc,sparc64: add syscall table generation support > >> linux-user,i386: add syscall table generation support > >> linux-user,x86_64: add syscall table generation support > >> linux-user,mips: add syscall table generation support > >> linux-user,mips64: split syscall_nr.h > >> linux-user,mips64: add syscall table generation support > >> linux-user,scripts: add a script to update syscall.tbl > >> linux-user: update syscall.tbl from linux 0bf999f9c5e7 > >> linux-user,mips: move content of mips_syscall_args > >> linux-user,mips: update syscall-args-o32.c.inc > > > > I suppose the patch subject was generated and you meant to use > > "linux-user/" instead of "linux-user,". Is that right? > > > > No, the idea is they touch "linux-user" subsystem and "ARCH" subsystem, > not especially the "linux-user/ARCH" directory > > I think Laurent's marks are appropriate, in fact, very useful for these areas of code. Elsewhere,,for example, one could use "softfoat,mips" for changes in softfloat affecting mips only. Regards, Aleksandar > Thanks, > Laurent > >
On 2/18/20 12:51 PM, Aleksandar Markovic wrote: > On Tuesday, February 18, 2020, Laurent Vivier <laurent@vivier.eu > <mailto:laurent@vivier.eu>> wrote: > > Le 18/02/2020 à 07:13, Philippe Mathieu-Daudé a écrit : > > On 2/17/20 11:35 PM, Laurent Vivier wrote: > >> This series copies the files syscall.tbl from linux v5.5 and > generates > >> the file syscall_nr.h from them. > >> > > [...] > >> Laurent Vivier (22): > >> linux-user: introduce parameters to generate syscall_nr.h > >> linux-user,alpha: add syscall table generation support > >> linux-user,hppa: add syscall table generation support > >> linux-user,m68k: add syscall table generation support > >> linux-user,xtensa: add syscall table generation support > >> linux-user,sh4: add syscall table generation support > >> linux-user,microblaze: add syscall table generation support > >> linux-user,arm: add syscall table generation support > >> linux-user,ppc: split syscall_nr.h > >> linux-user,ppc: add syscall table generation support > >> linux-user,s390x: remove syscall definitions for !TARGET_S390X > >> linux-user,s390x: add syscall table generation support > >> linux-user,sparc,sparc64: add syscall table generation support > >> linux-user,i386: add syscall table generation support > >> linux-user,x86_64: add syscall table generation support > >> linux-user,mips: add syscall table generation support > >> linux-user,mips64: split syscall_nr.h > >> linux-user,mips64: add syscall table generation support > >> linux-user,scripts: add a script to update syscall.tbl > >> linux-user: update syscall.tbl from linux 0bf999f9c5e7 > >> linux-user,mips: move content of mips_syscall_args > >> linux-user,mips: update syscall-args-o32.c.inc > > > > I suppose the patch subject was generated and you meant to use > > "linux-user/" instead of "linux-user,". Is that right? > > > > No, the idea is they touch "linux-user" subsystem and "ARCH" subsystem, > not especially the "linux-user/ARCH" directory > > > I think Laurent's marks are appropriate, in fact, very useful for these > areas of code. Elsewhere,,for example, one could use "softfoat,mips" for > changes in softfloat affecting mips only. Good example, thanks! > > Regards, > Aleksandar > > Thanks, > Laurent >
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?
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(). 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. Thanks, Laurent
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), unless someone complains -- maybe take the syscall.tbl from that state of the kernel tree as well?
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? > > >
On Tue, 18 Feb 2020 18:46:54 +0100 Aleksandar Markovic <aleksandar.m.mail@gmail.com> wrote: > On Tuesday, February 18, 2020, Cornelia Huck <cohuck@redhat.com> wrote: > > 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. I disagree. Not being able to do an update for a whole three months would block any of the features relying on kernel interfaces for the same time (or even longer, if the kernel release schedule aligns badly with QEMU freeze.) Issues with things being reverted in the Linux headers have been rare (and the ones I remember were because we did not merge from Linus master, but from some other tree that changed before being merged). I don't think it is worth slowing down development because of those rare issues.
On Mon, Feb 17, 2020 at 2:36 PM 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. What's the plan with these other architectures? RISC-V uses asm-generic, is there some way to generate syscall_nr.h from that? Alistair > > 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. > > Laurent Vivier (22): > linux-user: introduce parameters to generate syscall_nr.h > linux-user,alpha: add syscall table generation support > linux-user,hppa: add syscall table generation support > linux-user,m68k: add syscall table generation support > linux-user,xtensa: add syscall table generation support > linux-user,sh4: add syscall table generation support > linux-user,microblaze: add syscall table generation support > linux-user,arm: add syscall table generation support > linux-user,ppc: split syscall_nr.h > linux-user,ppc: add syscall table generation support > linux-user,s390x: remove syscall definitions for !TARGET_S390X > linux-user,s390x: add syscall table generation support > linux-user,sparc,sparc64: add syscall table generation support > linux-user,i386: add syscall table generation support > linux-user,x86_64: add syscall table generation support > linux-user,mips: add syscall table generation support > linux-user,mips64: split syscall_nr.h > linux-user,mips64: add syscall table generation support > linux-user,scripts: add a script to update syscall.tbl > linux-user: update syscall.tbl from linux 0bf999f9c5e7 > linux-user,mips: move content of mips_syscall_args > linux-user,mips: update syscall-args-o32.c.inc > > MAINTAINERS | 1 + > Makefile.target | 3 +- > configure | 23 + > linux-user/Makefile.objs | 19 +- > linux-user/alpha/Makefile.objs | 5 + > linux-user/alpha/syscall.tbl | 479 ++++++++++++++++ > linux-user/alpha/syscall_nr.h | 492 ----------------- > linux-user/alpha/syscallhdr.sh | 32 ++ > linux-user/arm/Makefile.objs | 8 + > linux-user/arm/syscall.tbl | 453 ++++++++++++++++ > linux-user/arm/syscall_nr.h | 447 --------------- > linux-user/arm/syscallhdr.sh | 31 ++ > linux-user/hppa/Makefile.objs | 5 + > linux-user/hppa/syscall.tbl | 437 +++++++++++++++ > linux-user/hppa/syscall_nr.h | 358 ------------ > linux-user/hppa/syscallhdr.sh | 32 ++ > linux-user/i386/Makefile.objs | 5 + > linux-user/i386/syscall_32.tbl | 444 +++++++++++++++ > linux-user/i386/syscall_nr.h | 387 ------------- > linux-user/i386/syscallhdr.sh | 28 + > linux-user/m68k/Makefile.objs | 5 + > linux-user/m68k/syscall.tbl | 439 +++++++++++++++ > linux-user/m68k/syscall_nr.h | 434 --------------- > linux-user/m68k/syscallhdr.sh | 32 ++ > linux-user/microblaze/Makefile.objs | 5 + > linux-user/microblaze/syscall.tbl | 445 +++++++++++++++ > linux-user/microblaze/syscall_nr.h | 442 --------------- > linux-user/microblaze/syscallhdr.sh | 32 ++ > linux-user/mips/Makefile.objs | 5 + > linux-user/mips/cpu_loop.c | 440 +-------------- > linux-user/mips/syscall-args-o32.c.inc | 436 +++++++++++++++ > linux-user/mips/syscall_nr.h | 425 --------------- > linux-user/mips/syscall_o32.tbl | 427 +++++++++++++++ > linux-user/mips/syscallhdr.sh | 36 ++ > linux-user/mips64/Makefile.objs | 9 + > linux-user/mips64/syscall_n32.tbl | 378 +++++++++++++ > linux-user/mips64/syscall_n64.tbl | 354 ++++++++++++ > linux-user/mips64/syscall_nr.h | 719 +------------------------ > linux-user/mips64/syscallhdr.sh | 33 ++ > linux-user/ppc/Makefile.objs | 9 + > linux-user/ppc/signal.c | 2 +- > linux-user/ppc/syscall.tbl | 521 ++++++++++++++++++ > linux-user/ppc/syscall_nr.h | 394 +------------- > linux-user/ppc/syscallhdr.sh | 34 ++ > linux-user/s390x/Makefile.objs | 5 + > linux-user/s390x/syscall.tbl | 442 +++++++++++++++ > linux-user/s390x/syscall_nr.h | 398 -------------- > linux-user/s390x/syscallhdr.sh | 32 ++ > linux-user/sh4/Makefile.objs | 5 + > linux-user/sh4/syscall.tbl | 442 +++++++++++++++ > linux-user/sh4/syscall_nr.h | 441 --------------- > linux-user/sh4/syscallhdr.sh | 32 ++ > linux-user/sparc/Makefile.objs | 5 + > linux-user/sparc/syscall.tbl | 485 +++++++++++++++++ > linux-user/sparc/syscall_nr.h | 363 ------------- > linux-user/sparc/syscallhdr.sh | 32 ++ > linux-user/sparc64/Makefile.objs | 5 + > linux-user/sparc64/syscall.tbl | 485 +++++++++++++++++ > linux-user/sparc64/syscall_nr.h | 366 ------------- > linux-user/sparc64/syscallhdr.sh | 32 ++ > linux-user/x86_64/Makefile.objs | 5 + > linux-user/x86_64/syscall_64.tbl | 404 ++++++++++++++ > linux-user/x86_64/syscall_nr.h | 356 ------------ > linux-user/x86_64/syscallhdr.sh | 28 + > linux-user/xtensa/Makefile.objs | 5 + > linux-user/xtensa/syscall.tbl | 410 ++++++++++++++ > linux-user/xtensa/syscall_nr.h | 469 ---------------- > linux-user/xtensa/syscallhdr.sh | 32 ++ > scripts/update-mips-syscall-args.sh | 57 ++ > scripts/update-syscalltbl.sh | 49 ++ > 70 files changed, 8201 insertions(+), 6929 deletions(-) > create mode 100644 linux-user/alpha/Makefile.objs > create mode 100644 linux-user/alpha/syscall.tbl > delete mode 100644 linux-user/alpha/syscall_nr.h > create mode 100644 linux-user/alpha/syscallhdr.sh > create mode 100644 linux-user/arm/Makefile.objs > create mode 100644 linux-user/arm/syscall.tbl > delete mode 100644 linux-user/arm/syscall_nr.h > create mode 100644 linux-user/arm/syscallhdr.sh > create mode 100644 linux-user/hppa/Makefile.objs > create mode 100644 linux-user/hppa/syscall.tbl > delete mode 100644 linux-user/hppa/syscall_nr.h > create mode 100644 linux-user/hppa/syscallhdr.sh > create mode 100644 linux-user/i386/Makefile.objs > create mode 100644 linux-user/i386/syscall_32.tbl > delete mode 100644 linux-user/i386/syscall_nr.h > create mode 100644 linux-user/i386/syscallhdr.sh > create mode 100644 linux-user/m68k/Makefile.objs > create mode 100644 linux-user/m68k/syscall.tbl > delete mode 100644 linux-user/m68k/syscall_nr.h > create mode 100644 linux-user/m68k/syscallhdr.sh > create mode 100644 linux-user/microblaze/Makefile.objs > create mode 100644 linux-user/microblaze/syscall.tbl > delete mode 100644 linux-user/microblaze/syscall_nr.h > create mode 100644 linux-user/microblaze/syscallhdr.sh > create mode 100644 linux-user/mips/Makefile.objs > create mode 100644 linux-user/mips/syscall-args-o32.c.inc > delete mode 100644 linux-user/mips/syscall_nr.h > create mode 100644 linux-user/mips/syscall_o32.tbl > create mode 100644 linux-user/mips/syscallhdr.sh > create mode 100644 linux-user/mips64/Makefile.objs > create mode 100644 linux-user/mips64/syscall_n32.tbl > create mode 100644 linux-user/mips64/syscall_n64.tbl > create mode 100644 linux-user/mips64/syscallhdr.sh > create mode 100644 linux-user/ppc/Makefile.objs > create mode 100644 linux-user/ppc/syscall.tbl > create mode 100644 linux-user/ppc/syscallhdr.sh > create mode 100644 linux-user/s390x/Makefile.objs > create mode 100644 linux-user/s390x/syscall.tbl > delete mode 100644 linux-user/s390x/syscall_nr.h > create mode 100755 linux-user/s390x/syscallhdr.sh > create mode 100644 linux-user/sh4/Makefile.objs > create mode 100644 linux-user/sh4/syscall.tbl > delete mode 100644 linux-user/sh4/syscall_nr.h > create mode 100644 linux-user/sh4/syscallhdr.sh > create mode 100644 linux-user/sparc/Makefile.objs > create mode 100644 linux-user/sparc/syscall.tbl > delete mode 100644 linux-user/sparc/syscall_nr.h > create mode 100644 linux-user/sparc/syscallhdr.sh > create mode 100644 linux-user/sparc64/Makefile.objs > create mode 100644 linux-user/sparc64/syscall.tbl > delete mode 100644 linux-user/sparc64/syscall_nr.h > create mode 100644 linux-user/sparc64/syscallhdr.sh > create mode 100644 linux-user/x86_64/Makefile.objs > create mode 100644 linux-user/x86_64/syscall_64.tbl > delete mode 100644 linux-user/x86_64/syscall_nr.h > create mode 100644 linux-user/x86_64/syscallhdr.sh > create mode 100644 linux-user/xtensa/Makefile.objs > create mode 100644 linux-user/xtensa/syscall.tbl > delete mode 100644 linux-user/xtensa/syscall_nr.h > create mode 100644 linux-user/xtensa/syscallhdr.sh > create mode 100755 scripts/update-mips-syscall-args.sh > create mode 100755 scripts/update-syscalltbl.sh > > -- > 2.24.1 > >
Le 18/02/2020 à 23:48, Alistair Francis a écrit : > On Mon, Feb 17, 2020 at 2:36 PM 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. > > What's the plan with these other architectures? > > RISC-V uses asm-generic, is there some way to generate syscall_nr.h from that? Automatically no. The best to do should be to convert linux parts using asm-generic to syscall.tbl and then after that using it in QEMU. Thanks, Laurent