Re: [PATCH] API: consolidate common unreleased enums

[Matthias Bolte <matthias.bolte@xxxxxxxxxxxxxx>]

2011/6/4 Daniel Veillard <veillard@xxxxxxxxxx>:
> 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, asked me on IRC to push this, so I did.

Matthias

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list