From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37992) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYqvM-0001pl-0X for qemu-devel@nongnu.org; Wed, 14 Nov 2012 23:19:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TYqvI-0003ms-V3 for qemu-devel@nongnu.org; Wed, 14 Nov 2012 23:19:31 -0500 Received: from e28smtp03.in.ibm.com ([122.248.162.3]:46815) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYqvI-0003kD-98 for qemu-devel@nongnu.org; Wed, 14 Nov 2012 23:19:28 -0500 Received: from /spool/local by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 15 Nov 2012 09:49:22 +0530 Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qAF4JHr120381718 for ; Thu, 15 Nov 2012 09:49:19 +0530 Received: from d28av02.in.ibm.com (loopback [127.0.0.1]) by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qAF9lPPX017992 for ; Thu, 15 Nov 2012 20:47:25 +1100 Message-ID: <50A46D1D.5040503@linux.vnet.ibm.com> Date: Thu, 15 Nov 2012 12:18:37 +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> In-Reply-To: <50A37325.9030607@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 于 2012-11-14 18:32, Paolo Bonzini 写道: > Il 14/11/2012 10:55, Wenchao Xia ha scritto: >>> In order to resolve OOM issue, I am trying wrap all APIs using >>> sunrpc, need some suggestion before coding. >> >> Is the client/server approach really necessary or can you write a >> library that invokes qemu-nbd/qemu-img? >> >> If there is a startup cost problem with qemu-img it may be possible to >> add an interactive mode (like qemu-io) where qemu-img stays open and >> responds to commands (maybe in JSON encoding). >> >> The difference between this and the RPC approach is that you can write a >> relatively thin NBD and qemu-img library with the tools that already >> exist today. > > In fact, I think this is not our issue. If libvirt wants to use > libqblock but have a problem with OOM exit, they can write their own > wrappers to do the simple tasks they need, or just keep on using > qemu-img with JSON output (possibly extending it and keeping the > functionality upstream). For many of those tasks, it may turn out that > qemu-img extensions would be useful anyway. > > Paolo > 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. 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. -- Best Regards Wenchao Xia