From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4Ifm-0001qD-Rr for qemu-devel@nongnu.org; Tue, 20 Apr 2010 14:59:50 -0400 Received: from [140.186.70.92] (port=49793 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4Ifk-0001o7-5y for qemu-devel@nongnu.org; Tue, 20 Apr 2010 14:59:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4Iff-0006r8-Mm for qemu-devel@nongnu.org; Tue, 20 Apr 2010 14:59:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12959) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4Iff-0006qs-83 for qemu-devel@nongnu.org; Tue, 20 Apr 2010 14:59:43 -0400 Message-ID: <4BCDF991.9050002@redhat.com> Date: Tue, 20 Apr 2010 20:59:29 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH v3 2/4] char: Add ability to provide a callback when write won't return -EAGAIN References: <1271319378-9811-1-git-send-email-amit.shah@redhat.com> <4BCD90C2.7050009@redhat.com> <20100420114420.GA20123@amit-x200.redhat.com> <201004201328.48953.paul@codesourcery.com> In-Reply-To: <201004201328.48953.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Amit Shah , qemu list On 04/20/10 14:28, Paul Brook wrote: >> I sent out this series as a "feeler" to see if the approach was >> acceptable. >> >> Paul didn't reply to my reply addressing his concern, so I take that as >> he's OK with the approach as well :-) > > I'd probably exposed this as an asyncronous write rather than nonblocking > operation. However both have their issues and I guess for character devices > your approach makes sense (c.f. block devices where we want concurrent > transfers). For chardevs async operation introduces ordering issues, I think supporting non-blocking writes is more useful here. > It would be useful to have a debugging mode where the chardev layer > deliberately returns spurious EAGAIN and short writes. Otherwise you've got a > lot of very poorly tested device fallback code. I have low confidence in > getting this right first time :-) It might be a good idea to have a different interface for it, i.e. qemu_chr_write() keeps current behavior and we'll add a new qemu_chr_write_nonblocking() for users which want (and can handle) the non-blocking behavior with short writes and -EAGAIN return values. We should also clearly define what qemu_chr_write_nonblocking() should do in case the underlying chardev backend doesn't support nonblocking operation. Option one is to fail and expect the caller handle the situation. Option two is fallback to blocking mode. I'd tend to pick option two, fallback to blocking mode is what the caller most likely will do anyway. cheers, Gerd