blob: 53c083fecdd5239a4f38a6b6c355b687caa794bc (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, I need to classify this bug report as either user-mode or system-mode related. Let's start by understanding the problem.
The issue is that a recent commit in libslirp broke QEMU's network stack when compiling for Windows. The error messages show pointer type mismatches involving SOCKET handler types. Specifically, functions expecting `slirp_os_socket` (which is a 64-bit type on Windows) are being passed functions that take an `int` instead.
QEMU uses libslirp for its user-mode networking stack, especially when using `-netdev user`. The network stack in this context isn't handling the SOCKET types correctly across different platforms. On Windows, sockets are represented as `SOCKET`, which is a 64-bit type, whereas on Linux, it's an `int`.
The problem arises during cross-compilation for Windows from a system like Fedora. The compilation fails because the pointer types don't match between libslirp's expected function signatures and QEMU's implementation.
This issue affects how QEMU handles networking in user-mode. It doesn't involve low-level hardware access or system privileges beyond what's typical for user-space applications. Instead, it's about correctly handling socket file descriptors across different operating systems within the application itself.
So, since the problem is related to the network stack implementation and cross-platform compatibility within a user-mode application (QEMU), this bug falls under 'user' category.
</think>
The issue pertains to QEMU's networking in user mode, specifically dealing with SOCKET types on Windows. Therefore, it's classified as a user-mode bug.
**Answer:** user
|