From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O9je6-0008Aa-13 for qemu-devel@nongnu.org; Wed, 05 May 2010 14:48:34 -0400 Received: from [140.186.70.92] (port=57613 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O9je4-0008AB-NO for qemu-devel@nongnu.org; Wed, 05 May 2010 14:48:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O9je2-0006dD-U4 for qemu-devel@nongnu.org; Wed, 05 May 2010 14:48:32 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:42361) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O9je2-0006cv-Jm for qemu-devel@nongnu.org; Wed, 05 May 2010 14:48:30 -0400 Received: by gwb15 with SMTP id 15so2350448gwb.4 for ; Wed, 05 May 2010 11:48:30 -0700 (PDT) Message-ID: <4BE1BD79.10004@codemonkey.ws> Date: Wed, 05 May 2010 13:48:25 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1273009170-17530-1-git-send-email-amit.shah@redhat.com> <1273009170-17530-2-git-send-email-amit.shah@redhat.com> <1273009170-17530-3-git-send-email-amit.shah@redhat.com> <1273009170-17530-4-git-send-email-amit.shah@redhat.com> <1273009170-17530-5-git-send-email-amit.shah@redhat.com> <4BE16FB5.6040708@codemonkey.ws> <4BE1BBB3.8050006@redhat.com> In-Reply-To: <4BE1BBB3.8050006@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 , Paul Brook , qemu list , Juan Quintela On 05/05/2010 01:40 PM, Gerd Hoffmann wrote: >>> + return s->chr_write_nb(s, buf, len); >>> +} >> >> I really dislike the idea of adding another function for this. > > Having a explicit function for non-blocking mode IMHO is much better. > It makes things more clear when reading the code. > > Previous approach was to check for O_NONBLOCK (extra syscall) and > behave differently depending on whenever it is set or not (too much > hidden magic). > >> Can you >> explain why you need this functionality for virtio-console and why this >> functionality isn't needed for everything else? > > virtio-console is just the first user. 16550 emulation can use that > too. With the blocking interface you'll stall the guest (sitting in > the blocking write syscall) in case the outgoing pipe is full. With > the non-blocking interface you can simply delay the "you can send more > data" signal (update status register + raise IRQ) until you can > actually accept more data. Meanwhile the guest can continue to run > and do something else. Basically it allows to implement sane flow > control. The use of char drivers is dominated by a small number of use cases which include serial ports, the monitor, and QMP. In all of those cases, the devices can and should participate in control flow. IMHO, we should make control flow part of the standard interface and fix all users appropriately. I've seen blocking result in frozen guests many times in real deployments. It's never the right thing to do as far as I can tell. Regards, Anthony Liguori > cheers, > Gerd >