From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KLcm9-0001sv-Tz for qemu-devel@nongnu.org; Wed, 23 Jul 2008 07:44:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KLcm8-0001rS-8D for qemu-devel@nongnu.org; Wed, 23 Jul 2008 07:44:57 -0400 Received: from [199.232.76.173] (port=38846 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KLcm8-0001rJ-1h for qemu-devel@nongnu.org; Wed, 23 Jul 2008 07:44:56 -0400 Received: from mx2.suse.de ([195.135.220.15]:49330) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KLcm7-0003oN-Jn for qemu-devel@nongnu.org; Wed, 23 Jul 2008 07:44:55 -0400 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 7D11345D60 for ; Wed, 23 Jul 2008 13:44:53 +0200 (CEST) Message-ID: <48871950.4000403@suse.de> Date: Wed, 23 Jul 2008 13:43:12 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/3] Always use nonblocking mode for qemu_chr_open_fd. References: <488688E3.105@codemonkey.ws> <4886FB17.5080202@suse.de> <18567.1320.117345.844400@mariner.uk.xensource.com> In-Reply-To: <18567.1320.117345.844400@mariner.uk.xensource.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Ian Jackson schrieb: > Kevin Wolf writes ("Re: [Qemu-devel] [PATCH 2/3] Always use nonblocking mode for qemu_chr_open_fd."): >> + if (strstart(filename, "nonblock:", &filename)) >> + block = 0; > > This is definitely wrong, because the need for (non)blocking behaviour > is determined statically by the code which is using the driver. It is better than what we have today because I can set non-blocking mode if I don't want to open the pty immediately and I can set blocking mode whenever I don't want to lose data and I'm sure to attach to the pty. This is a decision which your code cannot make statically but one which is influenced by which behaviour the user wants to have. Of course, you can always say "we can do even better". But as long as you don't provide code for non-blocking mode where all data is guaranteed to be delivered (and still works with a limited buffer...), it is reasonable to let the user decide. > Perhaps there should be two writing interfaces, qemu_chr_write and > qemu_chr_write_(non)block. And which one will be used if you don't want the user to decide? Kevin