blob: 7c2e964e9ed5e7ec22331c8f6b073eb3d1b6f1d5 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Alright, so I need to classify this bug report as either user-mode or system-mode related in QEMU. Let's break down the problem.
The issue is about user space emulation where certain syscalls like openat() are causing problems with path translation involving a sysroot. The user provided steps to reproduce involve compiling a test program and running it under qemu-arm, which I believe is the user-space emulator for ARM.
From what I know, QEMU has two main modes: system-mode (which emulates an entire OS, including hardware devices) and user-mode (which runs applications directly on the host kernel without full OS emulation). In user-mode, QEMU translates syscalls from one architecture to another.
The problem here seems to be with how paths are being translated when using openat(). The strace shows that opening /tmp is actually opening SYSROOT/tmp. Then, when using openat, it fails because the fd points into the sysroot instead of the expected location.
Since this involves handling file descriptors and path translations in user-space processes, without mentioning any hardware or low-level device interactions, it's likely a user-mode issue. System-mode would involve more about how the OS is running on virtualized hardware, not just application-level syscalls.
So, I think this bug falls under user-mode.
</think>
user
|