Re: [Qemu-devel] [RFC] libqblock OOM issue

[Wenchao Xia <xiawenc@linux.vnet.ibm.com>]

> 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