From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O9kE5-0005uX-Cr for qemu-devel@nongnu.org; Wed, 05 May 2010 15:25:45 -0400 Received: from [140.186.70.92] (port=39172 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O9kE4-0005sr-27 for qemu-devel@nongnu.org; Wed, 05 May 2010 15:25:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O9kE2-0004zP-GQ for qemu-devel@nongnu.org; Wed, 05 May 2010 15:25:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64272) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O9kE2-0004zE-9O for qemu-devel@nongnu.org; Wed, 05 May 2010 15:25:42 -0400 Message-ID: <4BE1C3F3.8080901@redhat.com> Date: Wed, 05 May 2010 21:16:03 +0200 From: Gerd Hoffmann 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> <4BE1785B.6010208@codemonkey.ws> <4BE1BC5D.6040909@redhat.com> <4BE1BDAC.50105@codemonkey.ws> In-Reply-To: <4BE1BDAC.50105@codemonkey.ws> 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: Anthony Liguori Cc: Amit Shah , Juan Quintela , Paul Brook , qemu list On 05/05/10 20:49, Anthony Liguori wrote: > On 05/05/2010 01:43 PM, Gerd Hoffmann wrote: >> On 05/05/10 15:53, Anthony Liguori wrote: >>> 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. >> >> Amit plans to add support to the others as well. Beside that there is >> a clearly defined backup plan: In case the non-blocking interface >> isn't supported by $chardev it will fallback to use the blocking mode. > > If we have a second interface, we'll have two interfaces forever. I'd > rather see us aggressive remove the blocking interface instead of > introducing a second interface. I'm all for killing the blocking interface. Problem is that converting over all users isn't exactly trivial and we have plenty of them. IMHO it isn't realistic to do the switch with a single patch series. cheers, Gerd