From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1ERV-00049d-6A for qemu-devel@nongnu.org; Mon, 12 Apr 2010 03:52:25 -0400 Received: from [140.186.70.92] (port=55621 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1ERS-00048z-P7 for qemu-devel@nongnu.org; Mon, 12 Apr 2010 03:52:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1ERR-0003ew-Cn for qemu-devel@nongnu.org; Mon, 12 Apr 2010 03:52:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7359) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1ERR-0003eN-5U for qemu-devel@nongnu.org; Mon, 12 Apr 2010 03:52:21 -0400 Message-ID: <4BC2D117.30307@redhat.com> Date: Mon, 12 Apr 2010 09:51:51 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1270674156-9345-1-git-send-email-amit.shah@redhat.com> <201004072358.53971.paul@codesourcery.com> In-Reply-To: <201004072358.53971.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 0/8] (v2) chardev, virtio-console: flow control, error handling, fixes List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Amit Shah , "Michael S. Tsirkin" , qemu list , Juan Quintela On 04/08/10 00:58, Paul Brook wrote: >> Hello, >> >> This patchset introduces flow control to virtio-console and >> chardev-based virtio serial ports. This series is based on the >> previous series I sent on Mar 31st (00/17: v4: virtio-serial fixes, >> new abi for port discovery) >> >> The qemu chardevs can now return -EAGAIN when a non-blocking remote >> isn't ready to accept more data. >> >> Comments? > > This is a major change in semantics. Are you sure all users handle this > correctly? My guess is that most of the devices don't. I don't expect trouble here. EAGAIN is returned only for file handles in non-blocking mode. I doubt existing users use non-blocking I/O as this makes the current unix_write() code go busy-loop in case the outgoing pipe is full. > EAGAIN isn't really a useful response unless you have some way of notifying > the device that it can send more data. This is a valid point though. cheers, Gerd