On Sat, May 05, 2007 at 12:00:49PM +0100, Richard W.M. Jones wrote:
> OK so this is step 2.5 out of 8 ... it wasn't part of the original plan.
> 
> 2.5 Export virGetDomain and virGetNetwork
> -----------------------------------------
> 
> M src/libvirt_sym.version
> M src/hash.c
> M src/internal.h
> 
> This patch exports virGetDomain and virGetNetwork functions as 
> "internal" functions (__virGetDomain and __virGetNetwork) for use by the 
> remote daemon.
> 
> The use is as follows: client needs to invoke a function such as 
> virDomainSuspend (virDomainPtr dom).  In order to do this it has to send 
> a reference to "dom" over the wire to the server, which it does by 
> encoding a remote_nonnull_domain XDR object (basically the name and 
> UUID).  On the server side we use virGetDomain to pull out the 
> corresponding virDomainPtr from the hash associated with the connection.

Looks reasonable. The only other alternative would be to explicitly 
lookup a domain by UUID on every call, eg 

    dom = virDomainLookupByUUID(uuid)
    ..do the work...
    virDomainFree(dom)

The virConnectPtr object has these objects cached so it wouldn't 
neccessarily be any slower this way. It would have the downside 
of slight semantic change - LookupByUUID may actually hit the
undering XenD apis if the cache was empty. This may make for hard 
to debug problems & complicate error reporting. So, I think it is
reasonable to export  virGetDomain & virGetNetwork to allow direct
use of the cache in this scenario.

Dan,
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to