From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49226) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYZi7-0006EU-Ld for qemu-devel@nongnu.org; Wed, 14 Nov 2012 04:56:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TYZi4-0001Xl-Ji for qemu-devel@nongnu.org; Wed, 14 Nov 2012 04:56:43 -0500 Received: from e28smtp02.in.ibm.com ([122.248.162.2]:52317) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYZi3-0001XS-UB for qemu-devel@nongnu.org; Wed, 14 Nov 2012 04:56:40 -0500 Received: from /spool/local by e28smtp02.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 14 Nov 2012 15:26:33 +0530 Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63]) by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qAE9uTG02949532 for ; Wed, 14 Nov 2012 15:26:29 +0530 Received: from d28av01.in.ibm.com (loopback [127.0.0.1]) by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qAEFQLGo005186 for ; Wed, 14 Nov 2012 15:26:21 GMT Message-ID: <50A36A90.9000402@linux.vnet.ibm.com> Date: Wed, 14 Nov 2012 17:55:28 +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> In-Reply-To: <20121114084509.GB23826@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; 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: Stefan Hajnoczi Cc: Kevin Wolf , Blue Swirl , Anthony Liguori , qemu-devel , Paolo Bonzini > On Wed, Nov 14, 2012 at 11:50:06AM +0800, Wenchao Xia wrote: >> 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. > > Stefan > I understand your reason about using qemu-img and qemu-nbd and appreciate for the suggestion. Currently libqblock already have the capabilities of r/w images as qemu-nbd, and have info retrieving capabilities as qemu-img. So the difference will be: using qemu-img qemu-nbd, it needs nbd client/json parser code, modification for qemu-img is needed for each new function added in libqblock. using rpc plus native lib, it needs good framework to transparently pass the information to client side for every API. IMHO, considering now libqblock have all the capabilities required except OOM, it is not hard to get same effect as using qemu-img and qemu-nbd, by wrapping read/write/info retrieve APIs if I keep the file stays open in server side and make server/client not mirrored. How to write a good enough framework which can wrap different API in an unified style, and keep this layer as simple, as transparent as possible, whether I should break the mirror between client/server, are some question I am not quite sure. -- Best Regards Wenchao Xia