From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O9fJP-00008n-HM for qemu-devel@nongnu.org; Wed, 05 May 2010 10:10:55 -0400 Received: from [140.186.70.92] (port=43663 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O9fJO-00007c-1P for qemu-devel@nongnu.org; Wed, 05 May 2010 10:10:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O9fJM-0002n5-3s for qemu-devel@nongnu.org; Wed, 05 May 2010 10:10:53 -0400 Received: from mx20.gnu.org ([199.232.41.8]:58398) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O9fJL-0002mw-V8 for qemu-devel@nongnu.org; Wed, 05 May 2010 10:10:52 -0400 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1O9fJL-0002Pd-5S for qemu-devel@nongnu.org; Wed, 05 May 2010 10:10:51 -0400 From: Paul Brook Date: Wed, 5 May 2010 15:10:48 +0100 References: <1273009170-17530-1-git-send-email-amit.shah@redhat.com> <201005051434.20020.paul@codesourcery.com> <4BE1785B.6010208@codemonkey.ws> In-Reply-To: <4BE1785B.6010208@codemonkey.ws> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005051510.48416.paul@codesourcery.com> Subject: [Qemu-devel] Re: [PATCH v7 4/6] char: Add qemu_chr_write_nb() for nonblocking writes List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Amit Shah , Juan Quintela , qemu list , Gerd Hoffmann > On 05/05/2010 08:34 AM, Paul Brook wrote: > >> I really dislike the idea of adding another function for this. Can you > >> explain why you need this functionality for virtio-console and why this > >> functionality isn't needed for everything else? > > > > This functionality should (in principle) be used by all serial port > > implementations. > > > > Physical serial ports are sufficiently crufty and low-performance that > > noone actually uses them nowadays. I expect that the only significant > > real-world use is for serial consoles, which never send enough data to > > care that writes stall the whole machine. > > We don't implement control flow in the character driver layer today. > Different backends use different policies. Some drop data (like pty) > while other block (like tcp). Really? I thought data was only dropped when no client was connected, and that there was a user visible option to control this. Either way, I agree that this should be done consistently. > This patch adds optional control flow in a pretty crufty way to *some* > backends but not all. This just adds a bunch of complexity that will > certainly introduce bugs. I admit I've only really looked at the device emulation side of the interface, not the chardev backend implementation. Paul