From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KLd5T-00078F-Pd for qemu-devel@nongnu.org; Wed, 23 Jul 2008 08:04:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KLd5S-00077W-3w for qemu-devel@nongnu.org; Wed, 23 Jul 2008 08:04:55 -0400 Received: from [199.232.76.173] (port=56393 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KLd5R-00077O-Ug for qemu-devel@nongnu.org; Wed, 23 Jul 2008 08:04:53 -0400 Received: from mx1.redhat.com ([66.187.233.31]:40194) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KLd5R-0000J3-Dh for qemu-devel@nongnu.org; Wed, 23 Jul 2008 08:04:53 -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 m6NC4rK6017751 for ; Wed, 23 Jul 2008 08:04:53 -0400 Received: from pobox.stuttgart.redhat.com (pobox.stuttgart.redhat.com [172.16.2.10]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6NC4pGU020690 for ; Wed, 23 Jul 2008 08:04:52 -0400 Received: from zweiblum.travel.kraxel.org (vpn-4-62.str.redhat.com [10.32.4.62]) by pobox.stuttgart.redhat.com (8.13.1/8.13.1) with ESMTP id m6NC4p0c003350 for ; Wed, 23 Jul 2008 08:04:51 -0400 Message-ID: <48871E62.2070504@redhat.com> Date: Wed, 23 Jul 2008 14:04:50 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/3] Always use nonblocking mode for qemu_chr_open_fd. References: <488688E3.105@codemonkey.ws> <4886FB17.5080202@suse.de> In-Reply-To: <4886FB17.5080202@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 Kevin Wolf wrote: > Anthony Liguori schrieb: >> 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. > > Then we need both. > > Add an option to specify non-blocking mode for stdio, pty and pipe in > qemu_chr_open. Blocking mode is used by default (maintaining current > semantics), non-blocking mode if the name is prefixed with nonblock: Doing that as config option is pusing the problem to the user and a quite lame way to address the problem. The IMHO best solution is to send data only if someone is connected to the slave device (assuming we find a way to figure that). Independant of that I think the char devices should move to non-blocking operation. That depends on the callers being able to handle qemu_chr_write() doing partial writes and -EAGAIN failures though. xenconsole code is doing fine here for example, but others probably depend on the current behavior. So it should probably the device emulation code which decides whenever it can run in non-blocking mode or not. cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/