From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KLT8e-0001HZ-9P
	for qemu-devel@nongnu.org; Tue, 22 Jul 2008 21:27:32 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KLT8c-0001Fc-MW
	for qemu-devel@nongnu.org; Tue, 22 Jul 2008 21:27:31 -0400
Received: from [199.232.76.173] (port=42779 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KLT8c-0001FW-HP
	for qemu-devel@nongnu.org; Tue, 22 Jul 2008 21:27:30 -0400
Received: from py-out-1112.google.com ([64.233.166.176]:59950)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1KLT8c-0006qw-9W
	for qemu-devel@nongnu.org; Tue, 22 Jul 2008 21:27:30 -0400
Received: by py-out-1112.google.com with SMTP id p76so1578427pyb.10
	for <qemu-devel@nongnu.org>; Tue, 22 Jul 2008 18:27:29 -0700 (PDT)
Message-ID: <488688E3.105@codemonkey.ws>
Date: Tue, 22 Jul 2008 20:26:59 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 2/3] Always use nonblocking mode for
	qemu_chr_open_fd.
References: <E1KJqa3-00067A-KN@mariner.uk.xensource.com>
In-Reply-To: <E1KJqa3-00067A-KN@mariner.uk.xensource.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

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.

Regards,

Anthony Liguori

> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  vl.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index 4f31288..c428c7e 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -2090,6 +2090,9 @@ static CharDriverState *qemu_chr_open_fd(int fd_in, int fd_out)
>      CharDriverState *chr;
>      FDCharDriver *s;
>  
> +    socket_set_nonblock(fd_in);
> +    socket_set_nonblock(fd_out);
> +
>      chr = qemu_mallocz(sizeof(CharDriverState));
>      if (!chr)
>          return NULL;
>