add 18th iteration of classifier

1 files changed, 44 insertions, 0 deletions

diff --git a/results/classifier/118/network/838974 b/results/classifier/118/network/838974
new file mode 100644
index 000000000..93e2ad6b6
--- /dev/null
+++ b/results/classifier/118/network/838974
@@ -0,0 +1,44 @@
+network: 0.905
+semantic: 0.872
+device: 0.802
+socket: 0.709
+risc-v: 0.680
+kernel: 0.672
+hypervisor: 0.669
+virtual: 0.664
+files: 0.660
+architecture: 0.648
+vnc: 0.646
+mistranslation: 0.645
+graphic: 0.645
+i386: 0.643
+register: 0.638
+ppc: 0.595
+KVM: 0.586
+peripherals: 0.576
+PID: 0.569
+arm: 0.557
+VMM: 0.554
+performance: 0.551
+x86: 0.530
+boot: 0.526
+TCG: 0.517
+debug: 0.493
+permissions: 0.470
+user-level: 0.384
+assembly: 0.359
+
+Confusing error report for missing vde support
+
+The error that appears in qemu 0.15 is "parameter 'type' expects a network client type" when trying to use vde for networking as if the parameter is wrong, but the problem is that the executable was compiled without vde support.
+
+Thanks for reporting this bug.
+
+That certainly could be confusing.  However, practically speaking, since qemu was compiled without that support, it becomes more difficult for qemu to tell the difference between a unsupported but otherwise-valid type, and an invalid type.
+
+Perhaps upstream would accept a (trivial) patch changing the message to always say "expects a valid network client type".  Even more helpful would be for that message to be followed by a list of valid, supported network types.
+
+I think this has been fixed by this commit here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d139e9a6cf01b8c31f59
+... so closing this ticket now.
+