From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4CZU-0005wi-Tf for qemu-devel@nongnu.org; Tue, 20 Apr 2010 08:28:56 -0400 Received: from [140.186.70.92] (port=37031 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4CZT-0005wP-I5 for qemu-devel@nongnu.org; Tue, 20 Apr 2010 08:28:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4CZR-0004qn-4U for qemu-devel@nongnu.org; Tue, 20 Apr 2010 08:28:55 -0400 Received: from mx20.gnu.org ([199.232.41.8]:49250) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4CZR-0004qi-2e for qemu-devel@nongnu.org; Tue, 20 Apr 2010 08:28:53 -0400 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1O4CZQ-0007Ai-6z for qemu-devel@nongnu.org; Tue, 20 Apr 2010 08:28:52 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH v3 2/4] char: Add ability to provide a callback when write won't return -EAGAIN Date: Tue, 20 Apr 2010 13:28:48 +0100 References: <1271319378-9811-1-git-send-email-amit.shah@redhat.com> <4BCD90C2.7050009@redhat.com> <20100420114420.GA20123@amit-x200.redhat.com> In-Reply-To: <20100420114420.GA20123@amit-x200.redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004201328.48953.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amit Shah Cc: Gerd Hoffmann , qemu list > 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). 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 :-) Paul