Le 12/02/2020 à 22:34, Laurent Vivier a écrit : > Le 04/02/2020 à 13:07, Aleksandar Markovic a écrit : >> From: Aleksandar Markovic <amarko...@wavecomp.com> >> >> Hello, folks! >> >> This series is a spin-off of another larger linux-user series >> that become too large to handle, hence these patches related to >> syscall numbers are now in this, separate, series. >> >> Now that kernel 5.5 is released few days ago, it is time to >> reflect what can be updated in linux-user for upcomming QEMU 5.0. >> >> An obvoius kernel change we should take into account are new >> system calls, and the foirst step is updating syscall numbers >> mainteined within QEMU linux-user. >> >> Regarding kernel syscal numbers there is good news and bad news. >> >> The good news is that kernel developers decided to make future >> syscall numbers much more synchonized accross architectures than >> before. They already reached that state. >> >> The bad news is that we in QEMU did not reach that state yet, since >> we lag after kernel significantly. >> >> The good news again is that we will reach that state if we update >> syscall numbers accross the board now. This is the main intention >> and motivation of this series. >> >> The bad news again is that in order to update syscall numebrs we >> need to be very careful at this moment. There are a number of new >> syscalls added to the kernel recently that QEMU doesn't know about >> at all. Significant number of new syscalls deal with 32/64-bit >> compatibility, traditionally a problematic area in kernel, and in >> QEMU as well. Moreover, some of the new syscalls are applicable to >> 32-bit architectures only. >> >> This series covers updating syscall numbers defined in the following >> files: >> >> - linux-user/alpha/syscall_nr.h >> - linux-user/arm/syscall_nr.h >> - linux-user/m68k/syscall_nr.h >> - linux-user/microblaze/syscall_nr.h >> - linux-user/mips/cpu_loop.c >> - linux-user/mips/syscall_nr.h >> - linux-user/mips64/syscall_nr.h >> - linux-user/sh4/syscall_nr.h >> - linux-user/x86_64/syscall_nr.h >> - linux-user/xtensa/syscall_nr.h >> >> This series doesn't cover following files (since they use certain >> proprietary rules for mapping between kernel source and qemu source, >> I don't feel quite comfortable changing them - therefore I am asking >> corresponding target maintainers or Lauren to update them, if >> possible, before our 5.0 release): >> >> - linux-user/aarch64/syscall_nr.h >> - linux-user/i386/syscall_nr.h >> - linux-user/nios2/syscall_nr.h >> - linux-user/ppc/syscall_nr.h >> - linux-user/riscv/syscall_nr.h >> - linux-user/s390x/syscall_nr.h >> - linux-user/sparc/syscall_nr.h >> - linux-user/sparc64/syscall_nr.h >> >> CC: Peter Maydell <peter.mayd...@linaro.org> >> CC: Paolo Bonzini <pbonz...@redhat.com> >> CC: Richard Henderson <r...@twiddle.net> >> CC: Eduardo Habkost <ehabk...@redhat.com> >> CC: Chris Wulff <crwu...@gmail.com> >> CC: Marek Vasut <ma...@denx.de> >> CC: David Gibson <da...@gibson.dropbear.id.au> >> CC: Palmer Dabbelt <pal...@dabbelt.com> >> CC: Alistair Francis <alistair.fran...@wdc.com> >> CC: Sagar Karandikar <sag...@eecs.berkeley.edu> >> CC: Bastian Koppelmann <kbast...@mail.uni-paderborn.de> >> CC: David Hildenbrand <da...@redhat.com> >> CC: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> >> CC: Artyom Tarasenko <atar4q...@gmail.com> >> >> This series also doesn't cover following files (since I can't find >> corresponding kernel code - and I am also asking corresponding >> target maintainers or Lauren to update them, if possible, before >> our 5.0 release): >> >> - linux-user/cris/cpu_loop.c >> - linux-user/hppa/syscall_nr.h >> - linux-user/openrisc/syscall_nr.h >> - linux-user/tilegx/syscall_nr.h >> >> CC: Edgar E. Iglesias <edgar.igles...@gmail.com> >> CC: Richard Henderson <r...@twiddle.net> >> CC: Stafford Horne <sho...@gmail.com> >> >> Again, I don't plan (I am really running out of time resources) to >> work in a significant way on this issue any more, and I am asking >> you guys other maintainers to help finish updating syscall numbers >> before QEMU 5.0 release. >> >> Once we do that, updating syscall numbers in QEMU should and will >> be significantly easier. >> > > I think we should copy the syscall.tbl and syscallhdr.sh scripts from > the linux tree and update syscallhdr.sh to generate our syscall_nr.h
I made a draft here: https://github.com/vivier/qemu/commits/linux-user-syscalltbl Thanks, Laurent