blob: 377c67b32ada1949d1995ed659004d6ed2fd3ab0 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, I need to figure out whether this bug report is classified as user-mode or system-mode in QEMU. Let me start by understanding the problem.
The user is using SLIRP with SMB on MacOS. They encountered an issue where mounting the SMB share fails because the smbd from macOS doesn't work with the same configuration as when running on Linux or FreeBSD. The solution was to compile Samba themselves and point QEMU to that binary.
Now, the user suggests adding a warning or error message in QEMU if it detects an incompatible smbd, like the one from macOS. They note that since smbd exits with an error code, QEMU could catch this and inform the user.
So, looking into QEMU's architecture, when using the -smb option, it's part of the user-mode networking setup because SLIRP is a userspace component. The network stack in user mode handles the SMB sharing without needing kernel-level privileges.
In contrast, system-mode (like when using KVM or other hypervisors) deals more with hardware virtualization and has different interactions.
Since this issue revolves around how QEMU interacts with an external smbd process in the userland environment, it's a user-mode problem. The bug affects the configuration and execution within user space, not involving kernel-level operations or device drivers.
</think>
user
|