blob: 4946940600c24a03ab5968f39101b2d5b99189d7 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, so I'm trying to figure out whether this bug report about QEMU is related to user-mode or system-mode. Let's break it down.
The user is running qemu-arm-static for the Git HEAD version and is encountering an issue when installing ghc from Debian into their arm chroot. The error messages mention "qemu: Unsupported syscall: 257 (timer_create)" and that both ghc and ghc-pkg are failing because timer_create isn't implemented.
First, I need to understand what each mode in QEMU refers to. User-mode emulation typically runs individual applications without a full OS, while system-mode emulates an entire operating system, including hardware devices and higher privilege levels.
In this case, the user is using a chroot environment, which suggests they're running a full system image inside QEMU. The error involves syscalls, specifically timer_create (syscall 257), which is part of the Linux kernel's capabilities. Since this syscall isn't supported by QEMU, it indicates that the problem arises when the emulated OS tries to use a system call that QEMU doesn't handle.
Since the user is installing software within a chroot (which implies a full system environment) and the error occurs during the installation process involving dpkg and post-installation scripts, this seems like a lower-level issue. These scripts likely require certain kernel features to function correctly, which in turn points to issues with how QEMU emulates the system calls required by the guest OS.
Therefore, this bug is more related to system-mode because it's about the overall emulation of the operating system and its syscalls rather than just running a single application.
</think>
system
|