From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O9f2j-0006xH-Qw for qemu-devel@nongnu.org; Wed, 05 May 2010 09:53:41 -0400 Received: from [140.186.70.92] (port=55498 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O9f2f-0006sy-Dk for qemu-devel@nongnu.org; Wed, 05 May 2010 09:53:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O9f2d-0008FB-Fh for qemu-devel@nongnu.org; Wed, 05 May 2010 09:53:37 -0400 Received: from mail-yx0-f191.google.com ([209.85.210.191]:52564) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O9f2d-0008Es-DD for qemu-devel@nongnu.org; Wed, 05 May 2010 09:53:35 -0400 Received: by yxe29 with SMTP id 29so1543244yxe.4 for ; Wed, 05 May 2010 06:53:34 -0700 (PDT) Message-ID: <4BE1785B.6010208@codemonkey.ws> Date: Wed, 05 May 2010 08:53:31 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1273009170-17530-1-git-send-email-amit.shah@redhat.com> <1273009170-17530-5-git-send-email-amit.shah@redhat.com> <4BE16FB5.6040708@codemonkey.ws> <201005051434.20020.paul@codesourcery.com> In-Reply-To: <201005051434.20020.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Paul Brook 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). 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. If we're going to make the char drivers implement control flow, then I think we should do it universally--not as an optional feature. For devices that can't participate in control flow, we should decide where the policy should be implemented (front-end or back-end) and in either approach, it's easy enough to make dropping data or blocking a choice. Regards, Anthony Liguori > With virtio-serial we've made serial ports a viable solution to a whole range > of problems. It's likely that applications that may send nontrivial amounts > of data, or clients will not be ready to process the data immediately. > > Paul >