[libvirt] [PATCH] API: consolidate common unreleased enums

[Matthias Bolte]

2011/6/4 Daniel Veillard <veillard at redhat.com>:
> 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