qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC] libqblock OOM issue
Date: Wed, 14 Nov 2012 09:55:29 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1

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*?

>   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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]