add 18th iteration of classifier

1 files changed, 82 insertions, 0 deletions

diff --git a/results/classifier/118/all/1180924 b/results/classifier/118/all/1180924
new file mode 100644
index 00000000..4cd4fb07
--- /dev/null
+++ b/results/classifier/118/all/1180924
@@ -0,0 +1,82 @@
+debug: 0.936
+register: 0.923
+user-level: 0.923
+permissions: 0.922
+hypervisor: 0.913
+semantic: 0.912
+peripherals: 0.906
+virtual: 0.894
+TCG: 0.893
+performance: 0.892
+assembly: 0.890
+mistranslation: 0.890
+graphic: 0.882
+architecture: 0.877
+risc-v: 0.876
+device: 0.867
+PID: 0.866
+arm: 0.865
+i386: 0.863
+KVM: 0.858
+ppc: 0.851
+vnc: 0.851
+files: 0.833
+boot: 0.833
+VMM: 0.823
+kernel: 0.794
+socket: 0.756
+network: 0.747
+x86: 0.741
+
+fails to handle a usb serial port with a specific vendorid
+
+If I run qemu-system-i386 with arguments
+-usb -usbdevice serial:vendorid=1221:pty
+(this is what the documentation says about how I shoud add a usb device which has a serial port interface and which has a specific vendor id, I used the documentation located here:
+http://qemu.weilnetz.de/qemu-doc.html
+), it says 
+char device redirected to /dev/pts/<something> (label usbserial0)
+qemu-system-i386: -usbdevice serial:vendorid=1221:pty: Property '.vendorid' not found
+Aborted
+and exits. Moreover, if I try to add such a device to a running machine by typing usb_add serial:vendorid=1221:pty in the machine's control terminal (to reach it, I press ctrl-alt-2), qemu also writes 
+char device redirected to /dev/pts/<something> (label usbserial0)
+Aborted
+to the terminal where I run it from and exits. To the quest OS this looks like a power failure which causes all the programs inside the virtual machine to lose their unsaved data.
+I have tested this with qemu-1.5.0-rc2, actually, the issue occured in a similar way since 1.0.1, but did not occur in 0.11.1.
+The issue is reproducible always, even if I don't specify any hard disk in the command line, i. e.
+$ qemu-system-i386 -usb -usbdevice serial:vendorid=1221:pty
+, so I believe it is guest OS -independent.
+
+  Hi,
+
+>> (this is what the documentation says about how I shoud add a usb device which has a serial port interface and which has a specific vendor id, I used the documentation located here:
+>> http://qemu.weilnetz.de/qemu-doc.html
+>> ), it says 
+>> char device redirected to /dev/pts/<something> (label usbserial0)
+>> qemu-system-i386: -usbdevice serial:vendorid=1221:pty: Property '.vendorid' not found
+>> Aborted
+> [...]
+> 
+> Regression; this definitely worked when I wrote docs/qdev-device-use.txt.
+
+> Not a release blocker, since it regressed a long time ago (v0.12).
+
+Guess the docs should be updated, unless someone can come up with a
+reasonable use case for the vendorid + deviceid properties.
+
+cheers,
+  Gerd
+
+
+I think the ability to specify a different vendorid + deviceid can be useful. Suppose there is a USB device such that the specifications are open and officially published, but the driver is proprietary. (As far as I know, this is similar to the situation with ATI video cards, but they are not USB devices.) And I suspect that the driver is buggy (i. e. it does not send the data according to the specifications). I want to figure out where exactly it works incorrectly to submit a bug report to the developer of the driver. Or suppose I have a physical device, but it works a bit incorrectly. I want to figure out where exactly the problem is, in the driver or in the device. Since I am not sure that the device is OK, I don't want to write my own driver and interact with the device, maybe I will damage it even more. In both cases, I can emulate the device according to the specifications, install the driver in a guest system, and then see whether the driver sends correct data or where and when exactly the data are incorrect.
+
+Anyway, I think it is more or less ok if qemu crashes right after it starts due to bad command line parameters (nevertherless, the functionality lost this way could be useful as I explained). But I think IT IS NOT OK WHEN A WORKING VM WITH PROGRAMS INSIDE CRASHES after user enters a bad command in the machine's control terminal, unless the user explicitly requests termination (e. g. enters the q command).
+
+Regressed in commit f29783f72ea77dfbd7ea0c993d62d253d4c4e023.
+
+I've just run into this in a similar circumstance: trying to reverse-engineer a driver for a phone to which I can only connect via Bluetooth. No problem, I can just have it pretend to be a USB device. Except that I can't, because the driver won't recognise it.
+
+The crash has now been fixed here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=aa612b364ecbe1dc
+Please also note that the "-usbdevice serial" syntax is considered as deprecated nowadays - use "-device usb-serial" instead.
+