add 18th iteration of classifier

1 files changed, 48 insertions, 0 deletions

diff --git a/results/classifier/118/network/676934 b/results/classifier/118/network/676934
new file mode 100644
index 000000000..b32c0ab67
--- /dev/null
+++ b/results/classifier/118/network/676934
@@ -0,0 +1,48 @@
+network: 0.812
+socket: 0.755
+device: 0.684
+mistranslation: 0.673
+virtual: 0.535
+graphic: 0.502
+semantic: 0.455
+ppc: 0.356
+peripherals: 0.353
+performance: 0.319
+arm: 0.313
+PID: 0.308
+boot: 0.300
+i386: 0.293
+permissions: 0.293
+kernel: 0.281
+risc-v: 0.258
+vnc: 0.242
+x86: 0.209
+TCG: 0.205
+debug: 0.198
+register: 0.166
+architecture: 0.138
+hypervisor: 0.108
+VMM: 0.094
+files: 0.085
+KVM: 0.056
+assembly: 0.044
+user-level: 0.041
+
+Ability to use -net socket with unix sockets
+
+It would be a nice feature (simplifying access control for example) to be able to do something like:
+
+qemu -net socket,listen=unix:/tmp/qemunet
+qemu -net socket,connect=unix:/tmp/qemunet
+
+For now one has to use TCP connections even for guests running on the same host, which involves setting up iptables to restrict access.
+
+Aren't these at different levels of the stack? Network devices deal in packets not connections. It sounds like you want to use something like vsock which provides a virtual socket device to the guest.
+
+This is just about connecting the NIC backends for 2 QEMUs together using a UNIX socket, instead of the current TCP/UDP socket. It should be fairly trivial to support i would expect. Though ideally we'd port the netdev socket backend to use QIOChannel  too
+
+
+This is an automated cleanup. This bug report got closed because it
+is a duplicate.
+
+