[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/9] linux-user: Update syscall numbers to kernel 5.5 level
From: |
Laurent Vivier |
Subject: |
Re: [PATCH 0/9] linux-user: Update syscall numbers to kernel 5.5 level |
Date: |
Wed, 12 Feb 2020 22:34:00 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 |
Le 04/02/2020 à 13:07, Aleksandar Markovic a écrit :
> From: Aleksandar Markovic <address@hidden>
>
> 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 <address@hidden>
> CC: Paolo Bonzini <address@hidden>
> CC: Richard Henderson <address@hidden>
> CC: Eduardo Habkost <address@hidden>
> CC: Chris Wulff <address@hidden>
> CC: Marek Vasut <address@hidden>
> CC: David Gibson <address@hidden>
> CC: Palmer Dabbelt <address@hidden>
> CC: Alistair Francis <address@hidden>
> CC: Sagar Karandikar <address@hidden>
> CC: Bastian Koppelmann <address@hidden>
> CC: David Hildenbrand <address@hidden>
> CC: Mark Cave-Ayland <address@hidden>
> CC: Artyom Tarasenko <address@hidden>
>
> 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 <address@hidden>
> CC: Richard Henderson <address@hidden>
> CC: Stafford Horne <address@hidden>
>
> 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 think it can be done in an easy way for most of our targets, except
some like mips that mixes o32, n32, n64 and a special table inside
cpu_loop.c
I will merge your patches (please update the mips one) as the work is
already done but I will have a look to try to generate them for the next
time from the kernel tables.
Thanks,
Laurent
- [PATCH 7/9] linux-user: x86_64: Update syscall numbers to kernel 5.5 level, (continued)
- [PATCH 7/9] linux-user: x86_64: Update syscall numbers to kernel 5.5 level, Aleksandar Markovic, 2020/02/04
- [PATCH 8/9] linux-user: xtensa: Update syscall numbers to kernel 5.5 level, Aleksandar Markovic, 2020/02/04
- [PATCH 5/9] linux-user: mips: Update syscall numbers to kernel 5.5 level, Aleksandar Markovic, 2020/02/04
- [PATCH 9/9] linux-user: xtensa: Remove unused constant TARGET_NR_syscall_count, Aleksandar Markovic, 2020/02/04
- [PATCH 1/9] linux-user: alpha: Update syscall numbers to kernel 5.5 level, Aleksandar Markovic, 2020/02/04
- [PATCH 6/9] linux-user: sh4: Update syscall numbers to kernel 5.5 level, Aleksandar Markovic, 2020/02/04
- Re: [PATCH 0/9] linux-user: Update syscall numbers to kernel 5.5 level, Aleksandar Markovic, 2020/02/04
- Re: [PATCH 0/9] linux-user: Update syscall numbers to kernel 5.5 level, Stafford Horne, 2020/02/05
- Re: [PATCH 0/9] linux-user: Update syscall numbers to kernel 5.5 level,
Laurent Vivier <=