From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47121) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYySi-00083N-R7 for qemu-devel@nongnu.org; Thu, 15 Nov 2012 07:22:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TYySf-0002v4-OW for qemu-devel@nongnu.org; Thu, 15 Nov 2012 07:22:28 -0500 Received: from e23smtp07.au.ibm.com ([202.81.31.140]:56376) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYySf-0002uq-6J for qemu-devel@nongnu.org; Thu, 15 Nov 2012 07:22:25 -0500 Received: from /spool/local by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 15 Nov 2012 22:18:14 +1000 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qAFCBnaW63176848 for ; Thu, 15 Nov 2012 23:11:50 +1100 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qAFCMDJ7012476 for ; Thu, 15 Nov 2012 23:22:13 +1100 Message-ID: <50A4DE35.2070706@linux.vnet.ibm.com> Date: Thu, 15 Nov 2012 20:21:09 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <50A313A5.8030500@linux.vnet.ibm.com> <50A314EE.6080801@linux.vnet.ibm.com> <20121114084509.GB23826@stefanha-thinkpad.redhat.com> <50A36A90.9000402@linux.vnet.ibm.com> <50A37325.9030607@redhat.com> <50A46D1D.5040503@linux.vnet.ibm.com> <50A4C48E.8080902@redhat.com> In-Reply-To: <50A4C48E.8080902@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] libqblock OOM issue List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , Stefan Hajnoczi , Anthony Liguori , qemu-devel , Blue Swirl > Il 15/11/2012 05:18, Wenchao Xia ha scritto: >> Personally agree, but I want to add a simple wrapper to let libqblock >> get user faster. In this way I guess best choice now is making rpc >> client and server not mirrored in implemention, server provides >> r/w/info retrieving capabilities via XDR protocol, client keeps >> the API unchanged but implement a bit different than server, which >> may archieve the same effect as invoking qemu-img inside without string >> parsing. > > I think the result would really not be simple... > yes it would not be very simple, I guess reimplement API on client side with RPC for only R/W/info APIs, would be relative easier than design a transparent and balanced RPC layer for every API. >> Not sure if libqblock now is blocked by OOM issue as 1st version to >> be reviewed. If you think it must be resolved first, I would add this >> wrapper quickly. > > No, I was lost with the build problems. Please repost the last version > you have. > > Paolo > OK, I'll rebase and repost it. -- Best Regards Wenchao Xia