On 05/12/2011 10:04 AM, Daniel P. Berrange wrote:
* src/remote/remote_protocol.x: Define wire protocol for migration protocol v3 * daemon/remote.c: Server side dispatch * src/remote/remote_driver.c: Client side serialization * src/remote/remote_protocol.c, src/remote/remote_protocol.h, daemon/remote_dispatch_args.h, daemon/remote_dispatch_prototypes.h, daemon/remote_dispatch_ret.h, daemon/remote_dispatch_table.h: Re-generate files * src/remote_protocol-structs: Declare new ABIs --- daemon/remote.c | 315 +++++++++++++++++++++++++++++++++++ src/remote/remote_driver.c | 370 +++++++++++++++++++++++++++++++++++++++++- src/remote/remote_protocol.x | 79 +++++++++- src/remote_protocol-structs | 90 ++++++++++ 4 files changed, 847 insertions(+), 7 deletions(-)
ACK; your rebase looks sane.
+struct remote_domain_migrate_begin3_args { + remote_nonnull_domain dom; + unsigned hyper flags; + remote_string dname; + unsigned hyper resource; +};
Unrelated to your patch, but do we need to think about the issues of dealing with 32-bit platforms? That is, if as a client on a 64-bit platform, connected to a 32-bit server, I call virDomainMigrate(...,0x100000000), it gets correctly transferred to the 64-bit hyper value over the wire. But then on the server side, the conversion of the 64-bit hyper back to a 32-bit long corrupts the value I passed, and ends up calling virDomainMigrate(...,0). In other words, I think we need some patches to our RPC protocol such that all longs are passed as hyper (necessary to avoid penalizing 64-to-64 communication), but range-checked for 32-bits (necessary for 64-to-32 communication), with an appropriate error issued if the RPC call can't proceed because of truncation issues. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org