From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O9kLU-00078m-39 for qemu-devel@nongnu.org; Wed, 05 May 2010 15:33:24 -0400 Received: from [140.186.70.92] (port=35947 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O9kLS-00077K-My for qemu-devel@nongnu.org; Wed, 05 May 2010 15:33:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O9kLR-00062r-0p for qemu-devel@nongnu.org; Wed, 05 May 2010 15:33:22 -0400 Received: from mail-yx0-f191.google.com ([209.85.210.191]:33552) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O9kLQ-00062k-P3 for qemu-devel@nongnu.org; Wed, 05 May 2010 15:33:20 -0400 Received: by yxe29 with SMTP id 29so1746763yxe.4 for ; Wed, 05 May 2010 12:33:20 -0700 (PDT) Message-ID: <4BE1C7FB.9050704@codemonkey.ws> Date: Wed, 05 May 2010 14:33:15 -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> <4BE1785B.6010208@codemonkey.ws> <4BE1BC5D.6040909@redhat.com> <4BE1BDAC.50105@codemonkey.ws> <4BE1C3F3.8080901@redhat.com> In-Reply-To: <4BE1C3F3.8080901@redhat.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: Gerd Hoffmann Cc: Amit Shah , Juan Quintela , Paul Brook , qemu list On 05/05/2010 02:16 PM, Gerd Hoffmann wrote: > 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. If we're agreed we ought to kill the blocking interface, let's define a new proper interface, rename all previous users to something ugly and deprecated, and approach it that way. Let's make it clear what interfaces are supported and which interfaces are scheduled to be removed. Regards, Anthony Liguori > cheers, > Gerd >