Re: [Qemu-devel] [PATCH 2/3] Always use nonblocking mode for qemu_chr_open_fd.

[Jamie Lokier]

Anthony Liguori wrote:
> I'm inclined to say that we simply declare that reconnecting to a PTY is 
> broken/unsupported and strongly encourage the use of something else 
> (like unix sockets).  That's always been my understanding FWIW.

As fas as I know, the usual way to use ptys is a program opens the
pty/tty pair, then it forks/execs a process which will use the tty
half.  The child might be the one to open the tty, but it is still
done so the parent knows the tty is open before it tries to use the
pty.

So it's not usual to have a pty open and _wait_ for the tty to open.

That said, a long time ago X11 used to use ptys and did something like
that.  I think it had a main pty, accessed exclusively, for initial
connection - and then allocated a pty/tty pair per individual
connection, freeing up the main one for another client.

To create a pty, and wait without polling for another process to
connect to the tty, this might work:

    1. Open the pty and tty _pair_, in the usual way.
       (openpt, grantpt, unlockpt etc.)
       Make sure the tty doesn't become controlling terminal - TIOCNOTTY.

    2. Keep the tty open, so you poll the pty for I/O as usual.
       Ignore the tty, just keep it open.

    3. Write whatever intro message appears on the pty, same way as
       with a socket.  No need to wait, the message is queued anyway.

    4. When the other process opens the tty, it will read the
       intro message.  When it writes something, QEMU will get read
       availability on the pty and process monitor commands as usual.

    5. If you want to support reconnects, close the tty in QEMU after
       read availabilty on the pty, so you receive EIO/POLLHUP from the pty
       when the other process is finished, or if it calls vhangup().
       Then reopen the tty with TIOCNOTTY, send another intro again.

       This seems like it won't handle a process which connects and
       sends nothing.  You might be able to use TIOCPKT to detect when
       the other process reads any of the intro message, I'm not sure.
       This would be better.

       Actually, if TIOCPKT works maybe you don't need to separately
       open the tty...

I'm not sure if this is complicated by controlling terminals,
sessions, process groups and SIGTTOU/SIGTTINs sent to the other
process, or if it just works out provided the tty descriptor in step 1
is opened with TIOCNOTTY.

-- Jamie