summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/118/none/1213196
blob: 60c344508ccabe919a7ad4684ada83c0dde28477 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
socket: 0.799
semantic: 0.557
device: 0.523
network: 0.502
ppc: 0.435
graphic: 0.422
performance: 0.408
kernel: 0.391
mistranslation: 0.363
PID: 0.337
files: 0.328
TCG: 0.325
vnc: 0.323
register: 0.252
boot: 0.251
risc-v: 0.249
arm: 0.236
x86: 0.232
virtual: 0.225
permissions: 0.218
i386: 0.209
architecture: 0.203
hypervisor: 0.193
peripherals: 0.192
VMM: 0.164
KVM: 0.146
debug: 0.145
user-level: 0.094
assembly: 0.066

-serial tcp should hang up when DTR goes low

In keeping with the spirit of serial modem control signals, de-asserting DTR should cause the TCP connection to break; asserting DTR should cause QEMU to initiate a new connection or for it to accept another (in server mode; this may involve waiting for one to arrive, too).

In addition to allowing low DTR to drop the socket connection, and allowing low DTR to reject a socket connection, the DCD modem bit also be implemented - DCD should follow the state of the TCP socket: a connected socket should pull DCD high, and a disconnected socket should pull DCD low. From what Ive seen in the source, it looks like a serial IOCTL functioned needs to be added to chardev/char-socket.c to allow the MSR bits to be tracked against the state of the socket.  DCD should be very easy to implement this way, but I hadn't thought about DTR.

Sent in a patch for this.

https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg04658.html

DTR controls the socket.

DCD reflects the state of the socket.




This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/97