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 [email protected] +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
