On Tue, May 31, 2011 at 11:00:04AM -0600, Eric Blake wrote:
> On 05/30/2011 07:03 AM, Matthias Bolte wrote:
>
> > From 726dae7b4c21d4c17ac19808c06d7fc978b36778 Mon Sep 17 00:00:00 2001
> > From: Matthias Bolte <matthias.bolte@xxxxxxxxxxxxxx>
> > Date: Mon, 30 May 2011 12:58:57 +0200
> > Subject: [PATCH] remote generator: Legacy support for hyper to long mappings
> >
> > Remove some special case code that took care of mapping hyper to the
> > correct C types.
>
> I like patch 1B better than 1A, so that's what I'm reviewing here.
>
> > +++ b/configure.ac
> > @@ -117,6 +117,7 @@ if test "x$have_cpuid" = xyes; then
> > fi
> > AC_MSG_RESULT([$have_cpuid])
> >
> > +AC_CHECK_SIZEOF(long)
>
> AC_CHECK_SIZEOF([long])
>
> so that we follow the autoconf recommended quoting rules.
>
> > +++ b/daemon/remote_generator.pl
> > @@ -174,6 +174,58 @@ while (<PROTOCOL>) {
> >
> > close(PROTOCOL);
> >
> > +# this dict contains the procedures that are allowed to map [unsigend] hyper
>
> s/unsigend/unsigned/
>
> > +# to [unsigend] long for legacy reasons in their signature and return type.
> > +# this list is fixed. new procedures and public APIs have to map [unsigend]
> > +# hyper to [unsigend] long long
>
> 3 more instances.
>
> > +my $long_legacy = {
> > + DomainGetMaxMemory => { ret => { memory => 1 } },
> > + DomainGetInfo => { ret => { maxMem => 1, memory => 1 } },
> > + DomainMigrate => { arg => { flags => 1, resource => 1 } },
> > + DomainMigrate2 => { arg => { flags => 1, resource => 1 } },
> > + DomainMigrateBegin3 => { arg => { flags => 1, resource => 1 } },
>
> Dan, DomainMigrate2 and DomainMigrateBegin3 are new APIs as of this
> release (similarly for other Migration v3 commands). Should these use
> 'long long' rather than 'long' for resource, as well as 'unsigned int'
> for flags, as part of your edict that all new APIs should avoid 'long'?
> Right _now_ is the time to make this change, before 0.9.2 goes gold.
The migration API situation is complex, because the public APIs
virDomainMigrate / MigrateToURI, call into different internal
methods based on migration protocol. Having the v3 migration
protocol use different size types to the v1 and v2 migration
protocols would be creating pain for ourselves IMHO.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list