3 files changed, 102 insertions, 0 deletions
diff --git a/results/classifier/108/other/938 b/results/classifier/108/other/938
new file mode 100644
index 000000000..0d3f61207
--- /dev/null
+++ b/results/classifier/108/other/938
@@ -0,0 +1,16 @@
+device: 0.714
+other: 0.417
+files: 0.251
+semantic: 0.246
+performance: 0.239
+PID: 0.195
+graphic: 0.185
+permissions: 0.184
+socket: 0.151
+boot: 0.149
+network: 0.098
+debug: 0.094
+vnc: 0.066
+KVM: 0.006
+
+Impossible to cross compile from Ubuntu or Debian to Windows with the tutorial
diff --git a/results/classifier/108/other/938552 b/results/classifier/108/other/938552
new file mode 100644
index 000000000..c762dfb3f
--- /dev/null
+++ b/results/classifier/108/other/938552
@@ -0,0 +1,43 @@
+performance: 0.878
+graphic: 0.860
+device: 0.835
+other: 0.801
+semantic: 0.707
+files: 0.706
+network: 0.583
+PID: 0.560
+boot: 0.546
+permissions: 0.534
+socket: 0.448
+KVM: 0.411
+vnc: 0.375
+debug: 0.353
+
+ENH: Inherit ptys, useful output from -serial pty
+
+When controlling a qemu instance from another program, it'd be very useful to be able to have qemu inherit pseudo-tty file descriptors so they could just be specified on the command line.
+
+It's possible to allocate a pty pair in the master program before forking and exec'ing qemu and have qemu use that pty, but it's a bit painful. The master program must call ptsname(...) on the fd of the slave side and insert the path to the pty device node into qemu's command line. This doesn't work well in many scripting languages which lack a ptsname() call; a Linux-specific hack like readlink() of /proc/self/fd/[slave-fd] is necessary.
+
+If qemu accepted file descriptors for serial I/O this would all be a lot more flexible, and it wouldn't be limited to ptys either. Just accept a new format for "-serial" like "-serial fd:7" and have the parent program not set that FD to close-on-exec.
+
+None of this would be as necessary if qemu's "-serial pty" option was fully functional. Unfortunately, it doesn't provide any information to associate the created PTY(s) with their qemu devices, so it's hard to know which serial port is which, which the monitor device is, etc. See, eg:
+
+$ qemu -serial pty -serial pty -monitor pty
+char device redirected to /dev/pts/6
+char device redirected to /dev/pts/7
+char device redirected to /dev/pts/8
+
+... which is which? Are they allocated in the order they're specified on the command line? Nope, because /dev/pts/6 is the monitor in this case. With more than one device using "pty" a lot of guesswork is involved.
+
+If you're using "-monitor stdio" you can issue an "info chardev" and parse that to find out what everything else is connected to, but this shouldn't really be necessary. Ideally the device names would be printed when a port is redirected to a pty, eg:
+
+$ qemu -serial pty -serial pty -monitor pty
+char device compat_monitor0 redirected to /dev/pts/6
+char device serial0 redirected to /dev/pts/7
+char device serial1 redirected to /dev/pts/8
+
+Looks like a fix for this has been included here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=586502189edf9fd0f89a83d
+... so I think it should be OK to close this ticket now.
+
diff --git a/results/classifier/108/other/938945 b/results/classifier/108/other/938945
new file mode 100644
index 000000000..43ab2af58
--- /dev/null
+++ b/results/classifier/108/other/938945
@@ -0,0 +1,43 @@
+graphic: 0.797
+device: 0.574
+performance: 0.567
+socket: 0.555
+semantic: 0.534
+network: 0.534
+other: 0.493
+permissions: 0.331
+KVM: 0.319
+PID: 0.283
+vnc: 0.261
+debug: 0.115
+files: 0.069
+boot: 0.039
+
+Slirp cannot be forward and makes segmentation faults
+
+Hi,
+
+Let's consider the following lines:
+
+$ qemu -enable-kvm -name opeth -hda debian1.img -k fr -localtime -m 512 -net user,vlan=0 -net nic,vlan=0,model=$model,macaddr=a2:00:00:00:00:10 -net socket,vlan=1,listen=127.0.0.1:5900 -net nic,vlan=1,model=$model,macaddr=a2:00:00:00:00:04
+
+$qemu -enable-kvm -name nightwish -hda debian2.img -k fr -localtime -m 512 -net socket,vlan=0,connect=127.0.0.1:5900 -net nic,vlan=0,model=$model,macaddr=a2:00:00:00:00:02
+
+
+My configuration is clear and allows to transmit packets between the Slirp and the guest nightwish.
+But when I try to do on nightwish :
+
+$ wget www.qemu.org
+
+The opeth QEMU makes a segfault :    "11586 Segmentation Fault"
+
+This phenomenon is not always present... If the Segfault does not appear, nightwish cannot enable a connection with internet :(
+
+
+Thanks
+Vince
+
+Which version of QEMU did you use? Can you still reproduce this issue with the latest version of QEMU?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+