From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:44034)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1TYyeD-0003b5-RT
	for qemu-devel@nongnu.org; Thu, 15 Nov 2012 07:34:24 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1TYyeA-0006cm-Nx
	for qemu-devel@nongnu.org; Thu, 15 Nov 2012 07:34:21 -0500
Received: from mx1.redhat.com ([209.132.183.28]:14012)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1TYyeA-0006cc-Fx
	for qemu-devel@nongnu.org; Thu, 15 Nov 2012 07:34:18 -0500
Message-ID: <50A4E143.5020207@redhat.com>
Date: Thu, 15 Nov 2012 13:34:11 +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> <50A37325.9030607@redhat.com>
	<50A46D1D.5040503@linux.vnet.ibm.com> <50A4C48E.8080902@redhat.com>
	<50A4DE35.2070706@linux.vnet.ibm.com>
In-Reply-To: <50A4DE35.2070706@linux.vnet.ibm.com>
Content-Type: text/plain; charset=ISO-8859-15
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 15/11/2012 13:21, 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.

So just let the libvirt people use it.  Then you will understand their
requirements.

Do not try to solve the world's problems at the first attempt.

Paolo