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 -=|