From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54156) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qnuyy-0002PL-3K for qemu-devel@nongnu.org; Mon, 01 Aug 2011 12:04:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qnuyx-0003JB-6E for qemu-devel@nongnu.org; Mon, 01 Aug 2011 12:04:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11119) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qnuyw-0003Iv-VF for qemu-devel@nongnu.org; Mon, 01 Aug 2011 12:04:43 -0400 Date: Mon, 1 Aug 2011 19:04:10 +0300 From: Alon Levy Message-ID: <20110801160410.GF2574@bow.tlv.redhat.com> References: <1312208590-25502-1-git-send-email-aliguori@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1312208590-25502-1-git-send-email-aliguori@us.ibm.com> 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: Anthony Liguori Cc: Amit Shah , Hans de Goede , qemu-devel@nongnu.org On Mon, Aug 01, 2011 at 09:22:58AM -0500, 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. > > One particularly nasty area is the mux device. I'm not entirely sure yet how > to preceed there. > > So, adding a copy - is that really a good idea? I don't have any alternative code, so I'm already starting bad, I know, and I understand the want to have a "middle ground" to ease the logic. Maybe keeping an iovec? add a function on each side for freeing, i.e. release_be_buffer, release_fe_buffer. At least it could make this as fast as the current code. I'm thinking of copy/paste for vdagent, usbredir, guest agent doing dmesg or anything larger.