On Fri, Jun 03, 2011 at 10:10:58AM -0600, Eric Blake wrote: > This commit is safe precisely because there has been no release > for any of the enum values being deleted (they were added post-0.9.1). > > After the 0.9.2 release, we can then take advantage of > virDomainModificationImpact in more places. > > * include/libvirt/libvirt.h.in (virDomainModificationImpact): New > enum. > (virDomainSchedParameterFlags, virMemoryParamFlags): Delete, since > these were never released, and the new enum works fine here. > * src/libvirt.c (virDomainGetMemoryParameters) > (virDomainSetMemoryParameters) > (virDomainGetSchedulerParametersFlags) > (virDomainSetSchedulerParametersFlags): Update documentation. > * src/qemu/qemu_driver.c (qemuDomainSetMemoryParameters) > (qemuDomainGetMemoryParameters, qemuSetSchedulerParametersFlags) > (qemuSetSchedulerParameters, qemuGetSchedulerParametersFlags) > (qemuGetSchedulerParameters): Adjust clients. > * tools/virsh.c (cmdSchedinfo, cmdMemtune): Likewise. > Based on ideas by Daniel Veillard and Hu Tao. > --- > > This has to be applied before 0.9.2 if we like the idea. > > See https://www.redhat.com/archives/libvir-list/2011-June/msg00177.html > for more details about why this is safe. I am intentionally not touching > any enums that existed in 0.9.1 at this point in the release cycle. > > include/libvirt/libvirt.h.in | 30 ++++++++------ > src/libvirt.c | 18 ++++---- > src/qemu/qemu_driver.c | 84 +++++++++++++++++++++--------------------- > tools/virsh.c | 12 +++--- > 4 files changed, 74 insertions(+), 70 deletions(-) > > diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in > index 8058229..df213f1 100644 > --- a/include/libvirt/libvirt.h.in > +++ b/include/libvirt/libvirt.h.in > @@ -142,6 +142,23 @@ typedef enum { > } virDomainCrashedReason; > > /** > + * virDomainModificationImpact: > + * > + * Several APIs take flags to determine whether a change to the domain > + * affects just the running instance, just the persistent definition, > + * or both. The use of VIR_DOMAIN_AFFECT_CURRENT will resolve to > + * either VIR_DOMAIN_AFFECT_LIVE or VIR_DOMAIN_AFFECT_CONFIG according > + * to current domain state. VIR_DOMAIN_AFFECT_LIVE requires a running > + * domain, and VIR_DOMAIN_AFFECT_CONFIG requires a persistent domain > + * (whether or not it is running). > + */ > +typedef enum { > + VIR_DOMAIN_AFFECT_CURRENT = 0, /* Affect current domain state. */ > + VIR_DOMAIN_AFFECT_LIVE = 1 << 0, /* Affect running domain state. */ > + VIR_DOMAIN_AFFECT_CONFIG = 1 << 1, /* Affect persistent domain state. */ > +} virDomainModificationImpact; > + > +/** > * virDomainInfoPtr: > * > * a virDomainInfo is a structure filled by virDomainGetInfo() and extracting > @@ -338,12 +355,6 @@ typedef virTypedParameter *virTypedParameterPtr; > > /* Management of scheduler parameters */ > > -typedef enum { > - VIR_DOMAIN_SCHEDPARAM_CURRENT = 0, /* affect current domain state */ > - VIR_DOMAIN_SCHEDPARAM_LIVE = (1 << 0), /* Affect active domain */ > - VIR_DOMAIN_SCHEDPARAM_CONFIG = (1 << 1), /* Affect next boot */ > -} virDomainSchedParameterFlags; > - > /* > * Fetch scheduler parameters, caller allocates 'params' field of size 'nparams' > */ > @@ -799,13 +810,6 @@ int virDomainGetBlkioParameters(virDomainPtr domain, > > /* Manage memory parameters. */ > > -/* flags for setting memory parameters */ > -typedef enum { > - VIR_DOMAIN_MEMORY_PARAM_CURRENT = 0, /* affect current domain state */ > - VIR_DOMAIN_MEMORY_PARAM_LIVE = (1 << 0), /* affect active domain */ > - VIR_DOMAIN_MEMORY_PARAM_CONFIG = (1 << 1) /* affect next boot */ > -} virMemoryParamFlags; > - > /** > * VIR_DOMAIN_MEMORY_PARAM_UNLIMITED: > * ACK, as stated before I think it's a good step to try to make the API more uniform across similar calls, and since there is more coming we should really do this, Please push before 0.9.2 (I will do it if not done before tomorrow evening my time), thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list