blob: 29772c3b62034d9236fe74147ed8553823fc1801 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, I'm trying to classify this bug report regarding QEMU as either user-mode or system-mode related. Let me break down the information provided.
The issue is about socket type mapping in a MIPS application-level emulation using QEMU's Linux-user mode. The problem occurs when an application calls `socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)`. Due to incorrect handling of socket types and flags like SOCK_NONBLOCK or SOCK_CLOEXEC, the system ends up receiving a different socket type (like SOCK_DGRAM), leading to an error.
The do_socket function in linux-user/syscall.c is where the problem lies. It's supposed to remap socket types for MIPS but doesn't account for these specific flags. The fix suggested involves masking off the flags before permutation and then handling them separately since MIPS uses different flag values.
Now, thinking about QEMU's modes: user-mode emulation (like linux-user) runs applications directly without a full OS, while system-mode emulates an entire system with hardware devices and peripherals.
This bug is in the do_socket function under linux-user, which is part of user-mode emulation. It's dealing with application-level syscalls and socket handling, not involving lower-level hardware or system-level privileges beyond what's needed for process emulation.
So, the issue is within the user-mode component because it affects how applications interact with system calls in a user-space context.
</think>
user
|