The most interesting or most complicated part here is the syscall_nr.h
generators. In order to keep the generation logic all in meson.build,
I am adding to config_target the name of the .tbl file, and making the
generated file syscall<SUFFIX>_nr.h for input file syscall<SUFFIX>.tbl.
For architectures where the input file is not named syscall_nr.tbl,
syscall_nr.h has to be a source file; it's just a forwarder for x86
(i386/x86_64), while for MIPS64 it chooses between N32 and N64 ABIs.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
x86, m68k, ppc, sh4 and sparc failed to enable timerfd, because they
didn't have timerfd_create system call defined. Instead QEMU
defined timerfd syscall. Checking with kernel sources, it appears
kernel developers reused timerfd syscall number with timerfd_create,
presumably since no userspace called the old syscall number.
Reported-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Riku Voipio <riku.voipio@linaro.org>
Sync syscall numbers to match the linux v4.5-rc1 kernel.
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Riku Voipio <riku.voipio@linaro.org>
The Linux syscalls underlying pread() and pwrite() take a 64 bit
offset on all architectures, even if some of them name the syscall
"pread/pwrite" rather than "pread64/pwrite64" for historical reasons.
So move the four QEMU target architectures (arm, i386, sparc,
unicore32) which were defining TARGET_NR_pread/pwrite to define
TARGET_NR_pread64/pwrite64 instead, and drop the TARGET_NR_pread/pwrite
implementation code completely.
(Based on examination of the kernel sources for the four architectures
this patch affects.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Add syscall numbers for new syscall numbers; this brings us
into line with Linux 2.6.39.2.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Riku Voipio <riku.voipio@linaro.org>
