[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] libqblock OOM issue
From: |
Wenchao Xia |
Subject: |
Re: [Qemu-devel] [RFC] libqblock OOM issue |
Date: |
Wed, 14 Nov 2012 18:06:55 +0800 |
User-agent: |
Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 |
> 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