From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:37717)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1TYaGe-0000qn-OJ
	for qemu-devel@nongnu.org; Wed, 14 Nov 2012 05:32:27 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1TYaGb-0004GV-Mw
	for qemu-devel@nongnu.org; Wed, 14 Nov 2012 05:32:24 -0500
Received: from mx1.redhat.com ([209.132.183.28]:60456)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1TYaGb-0004Fp-EO
	for qemu-devel@nongnu.org; Wed, 14 Nov 2012 05:32:21 -0500
Message-ID: <50A37325.9030607@redhat.com>
Date: Wed, 14 Nov 2012 11:32:05 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
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>
In-Reply-To: <50A36A90.9000402@linux.vnet.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC] libqblock OOM issue
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com>, Anthony Liguori <aliguori@us.ibm.com>, qemu-devel <qemu-devel@nongnu.org>, Blue Swirl <blauwirbel@gmail.com>

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