From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42287) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qo1Gi-0008Pp-69 for qemu-devel@nongnu.org; Mon, 01 Aug 2011 18:47:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qo1Gf-000262-Uj for qemu-devel@nongnu.org; Mon, 01 Aug 2011 18:47:27 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:60032) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qo1Gf-00025Z-Hp for qemu-devel@nongnu.org; Mon, 01 Aug 2011 18:47:25 -0400 Received: by gyg8 with SMTP id 8so4466090gyg.4 for ; Mon, 01 Aug 2011 15:47:24 -0700 (PDT) Message-ID: <4E372CFA.105@codemonkey.ws> Date: Mon, 01 Aug 2011 17:47:22 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1312208590-25502-1-git-send-email-aliguori@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 00/12][RFC] char: add flow control and fix guest_[open|close] List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Amit Shah , Hans de Goede , qemu-devel@nongnu.org On 08/01/2011 04:54 PM, Blue Swirl wrote: > On Mon, Aug 1, 2011 at 2:22 PM, Anthony Liguori wrote: >> The char layer has been growing some nasty warts for some time now as we ask it >> to do things it was never intended on doing. It's been long over due for an >> overhaul and its become evident to me that we need to address this first before >> adding any more features to the char layer. >> >> This series is the start at sanitizing the char layer. It effectively turns >> the char layer into an internal pipe. It supports flow control using an >> intermediate ring queue for each direction. >> >> This series is an RFC because I don't think we should merge the series until we >> completely convert the old style flow control users to the new style. > > The terms 'back-end' and 'front-end' could be improved. How about just > 'device' or 'hw' and 'chrdev'? It's all temporary as there currently is very little asymmetry. Historically, the biggest source of asymmetry was the fact that the back-end -> front-end path had flow control and the opposite direction didn't. This series fixes that. The only remaining asymmetry is the ioctl() call. I think if we change the semantics of qemu_chr_event() though to have a return value and a data parameter, I think we can fold ioctl into event and ultimately fix that asymmetry. Once that's done, there's no longer a distinction between front-end and back-end. That makes CharDriverState act as basically a socketpair(). > > The architecture could be described in for example qemu-tech.texi. I'll include something for docs/ for the next submission. Regards, Anthony Liguori