auto-virtserial: Explain how test_blocking_read() works

There's some hackery in the way test_blocking_read() works, document it
so that the move to autotest is easier.

Signed-off-by: Amit Shah <amit.shah@redhat.com>

1 files changed, 13 insertions, 0 deletions

diff --git a/auto-virtserial.c b/auto-virtserial.c
index 54c35a2..260825b 100644
--- a/auto-virtserial.c
+++ b/auto-virtserial.c
@@ -437,6 +437,19 @@ static int test_blocking_read(int nr)
 	gpkt.value = nr;
 	guest_cmd_only(&gpkt);
 
+	/*
+	 * We'll try to be a little smart here: The guest is blocked
+	 * on read, so we can't start a poll() request in the same
+	 * thread. so either we spawn off the blocking read in a
+	 * different thread or we poll our controlling port for the
+	 * response from the read syscall (the guest will immediately
+	 * write the return value from the read() syscall once it
+	 * comes out of its blocking state).
+	 *
+	 * So what we do here is poll on the control port for the read
+	 * response. If there is any, it means the guest came out of
+	 * its blocking read.
+	 */
 	pollfd[0].fd = chardevs[1].sock;
 	pollfd[0].events = POLLIN;
 	/* See if we get something in 5s -- we shouldn't. */