From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KLdIx-0006bu-TZ
	for qemu-devel@nongnu.org; Wed, 23 Jul 2008 08:18:51 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KLdIv-0006bP-HJ
	for qemu-devel@nongnu.org; Wed, 23 Jul 2008 08:18:50 -0400
Received: from [199.232.76.173] (port=56882 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KLdIv-0006bM-Ca
	for qemu-devel@nongnu.org; Wed, 23 Jul 2008 08:18:49 -0400
Received: from mail.codesourcery.com ([65.74.133.4]:44963)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1KLdIu-0003BM-Km
	for qemu-devel@nongnu.org; Wed, 23 Jul 2008 08:18:49 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH 2/3] Always use nonblocking
	=?iso-8859-1?q?mode=09for=09qemu=5Fchr=5Fopen=5Ffd=2E?=
Date: Wed, 23 Jul 2008 13:18:42 +0100
References: <E1KJqa3-00067A-KN@mariner.uk.xensource.com>
	<4886FB17.5080202@suse.de> <48871E62.2070504@redhat.com>
In-Reply-To: <48871E62.2070504@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200807231318.43140.paul@codesourcery.com>
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
Cc: Gerd Hoffmann <kraxel@redhat.com>

> >> 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.

I agree. Char devices should never drop data when a user is connected. If we 
can't tell whether a user is connected we should never drop data at all, and 
it's the user's responsibility to ensure data doesn't back up.

Paul