From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54515) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYZsn-0002Lj-0q for qemu-devel@nongnu.org; Wed, 14 Nov 2012 05:07:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TYZsj-0004zO-UK for qemu-devel@nongnu.org; Wed, 14 Nov 2012 05:07:44 -0500 Received: from e23smtp03.au.ibm.com ([202.81.31.145]:44348) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYZsj-0004zH-As for qemu-devel@nongnu.org; Wed, 14 Nov 2012 05:07:41 -0500 Received: from /spool/local by e23smtp03.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 14 Nov 2012 20:04:19 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qAE9v78C37158972 for ; Wed, 14 Nov 2012 20:57:08 +1100 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qAEA7Ttq020061 for ; Wed, 14 Nov 2012 21:07:30 +1100 Message-ID: <50A36D3F.4080001@linux.vnet.ibm.com> Date: Wed, 14 Nov 2012 18:06:55 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <50A313A5.8030500@linux.vnet.ibm.com> <50A314EE.6080801@linux.vnet.ibm.com> <50A35C81.2020602@redhat.com> In-Reply-To: <50A35C81.2020602@redhat.com> Content-Type: text/plain; charset=GB2312 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 14/11/2012 04:50, Wenchao Xia ha scritto: >> There are some different way to implement, not sure which would be >> better: >> 1 keep client as thin as possible, client stores opaque pointer used >> in server side, for eg, QBlockContext *ctx, client only get a pointer >> pointing to the address where server stores really the object. This >> have risk when server/client crash and reconnect. >> 2 client and server maintains index for QBlockContext and QBlockState. >> 3 thick client and server layer, expose all structure details in .x >> file, each API have a correspond rpc call. .x file may be complex. >> 4 define a custom protocol on XDR, like libvirt, this may need many >> code in server/client side. >> >> also with method 1-3, Consider wrapping following API: >> int qb_context_new(QBlockContext **context); > > What is the return value of qb_context_new? Can it simply return > QBlockContext*? > Yes it can return QBlockContext*. There are more APIs take 3 or 4 parameters, which may be used to retrieve result. In that case I am afraid a return structure can't be avoided, this may result .x file looks strange. >> The parameter context is a pointer that will be modified, it seems >> sunrpc does not transfer back modified parameter by server to client, so >> I need to define a structure as >> struct qb_context_new_ret { >> int ret; >> int opaque_len; >> char *opaque_val; >> } >> and use that as rpc call's return structure. In this way each API >> wrapped need a new defined internal structure make things complicate. >> so I am wondering if there is a better way to do it. > > Surely not all of the APIs return structs this way, however... > > Paolo > -- Best Regards Wenchao Xia