From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KLjMN-0007kU-B5 for qemu-devel@nongnu.org; Wed, 23 Jul 2008 14:46:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KLjMK-0007ho-KP for qemu-devel@nongnu.org; Wed, 23 Jul 2008 14:46:46 -0400 Received: from [199.232.76.173] (port=57139 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KLjMJ-0007hi-Rs for qemu-devel@nongnu.org; Wed, 23 Jul 2008 14:46:44 -0400 Received: from mail2.shareable.org ([80.68.89.115]:45770) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KLjMJ-0001MV-Md for qemu-devel@nongnu.org; Wed, 23 Jul 2008 14:46:43 -0400 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1KLjho-0005YZ-GA for qemu-devel@nongnu.org; Wed, 23 Jul 2008 20:08:56 +0100 Date: Wed, 23 Jul 2008 20:08:56 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 2/3] Always use nonblocking mode for qemu_chr_open_fd. Message-ID: <20080723190856.GA20800@shareable.org> References: <20080723082413.GA2291@redhat.com> <48871A7E.5030501@redhat.com> <20080723121510.GJ2291@redhat.com> <48872979.4050107@redhat.com> <48873F17.4030101@redhat.com> <48874D4A.8000604@codemonkey.ws> <20080723153133.GL2291@redhat.com> <48874F0B.3040609@codemonkey.ws> <4887598B.8070405@redhat.com> <48875D48.8030906@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48875D48.8030906@codemonkey.ws> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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