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