From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KLZe3-0003tz-E5 for qemu-devel@nongnu.org; Wed, 23 Jul 2008 04:24:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KLZe0-0003tI-R3 for qemu-devel@nongnu.org; Wed, 23 Jul 2008 04:24:22 -0400 Received: from [199.232.76.173] (port=59439 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KLZe0-0003tF-OM for qemu-devel@nongnu.org; Wed, 23 Jul 2008 04:24:20 -0400 Received: from mx1.redhat.com ([66.187.233.31]:54052) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KLZe0-0003zN-8U for qemu-devel@nongnu.org; Wed, 23 Jul 2008 04:24:20 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m6N8OEJ4005461 for ; Wed, 23 Jul 2008 04:24:14 -0400 Received: from file.fab.redhat.com (file.fab.redhat.com [10.33.63.6]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6N8ODaJ024250 for ; Wed, 23 Jul 2008 04:24:13 -0400 Received: (from berrange@localhost) by file.fab.redhat.com (8.13.1/8.13.1/Submit) id m6N8ODmI003164 for qemu-devel@nongnu.org; Wed, 23 Jul 2008 09:24:13 +0100 Date: Wed, 23 Jul 2008 09:24:13 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH 2/3] Always use nonblocking mode for qemu_chr_open_fd. Message-ID: <20080723082413.GA2291@redhat.com> References: <488688E3.105@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <488688E3.105@codemonkey.ws> Reply-To: "Daniel P. Berrange" , 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 On Tue, Jul 22, 2008 at 08:26:59PM -0500, Anthony Liguori wrote: > Hi, > > Ian Jackson wrote: > >The rest of qemu assumes that IO operations on a CharDriverState do > >not block. Currently there are a couple of cases where such a driver > >was set up but the calls to set nonblocking mode were missing: > > * qemu_chr_open_pty > > * qemu_chr_open_pipe > > * qemu_chr_open_stdio > > > >This is fixed by adding two calls to socket_set_nonblock to > >qemu_chr_open_fd. > > > > This changes semantics a bit. Previously, using a pty would guarantee > that data is always written as qemu_chr_write does not perform any sort > of buffering. > > Now, that data will be silently dropped instead of causing QEMU to > block. I don't think it's perfectly clear that one behaviour is clearly > better than the other. In the case of the PTY backend, the only time I'd expect data to be dropped is if there was no active slave open. If an application has the PTY open and is interacting, then I'd want to get all data. My use case is that all VMs started will have a serial port configured with '-serial pty'. The guest OS should not be blocked when writing to the serial port if no one has the PTY open on the host, but if someone attaches to it with 'virsh console' then I want to be guartenteed to get all data. Daniel. -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|