On 10/25/2011 05:51 PM, Eric Blake wrote:
Shoot, we have another problem. The current Get interfaces are
documented as returning 0 on success, rather than the number of
successfully returned elements. virDomainGetSchedulerParameters is
hard-wired in the RPC protocol to not pass an array length, a
On Wed, Oct 12, 2011 at 05:26:34PM +0800, Hu Tao wrote:
> This makes string can be transported between client and server.
> For compatibility,
>
> o new server should not send strings to old client if it
> doesn't see the flag VIR_DOMAIN_TYPED_STRING_OKAY.
> o new client that wants t
On 10/25/2011 03:31 PM, Eric Blake wrote:
Here's what I'm squashing in:
Good thing I haven't pushed yet - I just realized another problem.
But on Get interfaces, like virDomainGetMemoryParamaters, params is an
output-only interface; it can be uninitialized memory on entry, so we
must not ba
On 10/25/2011 02:59 PM, Eric Blake wrote:
On 10/12/2011 03:26 AM, Hu Tao wrote:
Apologies on the delayed review, but I'm finally getting to this one.
That just goes to show that a lot has
happened in libvirt.c since this patch was proposed.
...
Here's what I'm squashing in:
Good thing I h
On 10/12/2011 03:26 AM, Hu Tao wrote:
Apologies on the delayed review, but I'm finally getting to this one.
This makes string can be transported between client and server.
For compatibility,
o new server should not send strings to old client if it
doesn't see the flag VIR_DOMAIN_TY
This makes string can be transported between client and server.
For compatibility,
o new server should not send strings to old client if it
doesn't see the flag VIR_DOMAIN_TYPED_STRING_OKAY.
o new client that wants to be able to send/receive strings
should always set the flag V
