[libvirt] [PATCH] [2/4] Implement remote protocol for managed save

Daniel Veillard veillard at redhat.com
Sun Apr 4 09:24:56 UTC 2010


On Fri, Apr 02, 2010 at 05:29:58PM -0400, Chris Lalancette wrote:
> On 04/02/2010 04:56 PM, Daniel Veillard wrote:
> > diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x
> > index f86c7f1..0374f9a 100644
> > --- a/src/remote/remote_protocol.x
> > +++ b/src/remote/remote_protocol.x
> > @@ -1657,6 +1657,10 @@ struct remote_domain_has_managed_save_image_args {
> >      unsigned flags;
> >  };
> >  
> > +struct remote_domain_has_managed_save_image_ret {
> > +    int ret;
> > +};
> > +
> 
> Hm, I don't think this is necessary.  I think the return value is always going
> to be an int, so you should just be able to return -1, 0, or 1 in the remote
> driver as necessary.

  My initial reaction was the same, then I looked at GetMaxVcpus and
other examples and converted the code accordingly.

> At least, that's how all of the other things that return
> numbers (such as virDomainNumDefinedDomains) work.

In the cases I checked and looked for it seems the network call()
return values is always 0 or -1, and looking at virDomainGetMaxVcpus()
it does use

struct remote_domain_get_max_vcpus_ret {
    int num;
};

  same for virDomainNumDomains()

and I also see

struct remote_num_of_defined_domains_ret {
    int num;
};

 in the src/remote/remote_protocol.x right now,
remoteNumOfDefinedDomains( does use  remote_num_of_defined_domains_ret ret;
and remoteDispatchNumOfDefinedDomains() do use a
remote_num_of_defined_domains_ret *ret argument, so I'm wondering if we
are really looking at the same code.

  In the case we just return 0 for success and -1 in case of error, we
clearly don't need the return structure, but all examples I checked for
an full int reurn used a structure. So I assume the change is needed,
or at least it's safe :-)

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/




More information about the libvir-list mailing list