[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH libvirt-glib] gobject: add GVir.DomainShutdownFlags binding



Hey

On Fri, Aug 3, 2012 at 12:20 PM, Christophe Fergeau <cfergeau redhat com> wrote:
> Hey,
>
> On Thu, Jul 19, 2012 at 07:36:50PM +0200, Marc-André Lureau wrote:
>> ---
>>  libvirt-gobject/libvirt-gobject-domain.c |    2 +-
>>  libvirt-gobject/libvirt-gobject-domain.h |   13 +++++++++++++
>>  libvirt-gobject/libvirt-gobject.sym      |    1 +
>>  3 files changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/libvirt-gobject/libvirt-gobject-domain.c b/libvirt-gobject/libvirt-gobject-domain.c
>> index ba8e12b..d12ac97 100644
>> --- a/libvirt-gobject/libvirt-gobject-domain.c
>> +++ b/libvirt-gobject/libvirt-gobject-domain.c
>> @@ -509,7 +509,7 @@ gboolean gvir_domain_delete(GVirDomain *dom,
>>  /**
>>   * gvir_domain_shutdown:
>>   * @dom: the domain
>> - * @flags:  the flags
>> + * @flags:  the %GVirDomainShutdownFlags flags
>>   */
>>  gboolean gvir_domain_shutdown(GVirDomain *dom,
>>                                guint flags G_GNUC_UNUSED,
>> diff --git a/libvirt-gobject/libvirt-gobject-domain.h b/libvirt-gobject/libvirt-gobject-domain.h
>> index 70e7e37..c61a2f5 100644
>> --- a/libvirt-gobject/libvirt-gobject-domain.h
>> +++ b/libvirt-gobject/libvirt-gobject-domain.h
>> @@ -116,6 +116,19 @@ typedef enum {
>>      GVIR_DOMAIN_XML_UPDATE_CPU      = VIR_DOMAIN_XML_UPDATE_CPU,
>>  } GVirDomainXMLFlags;
>>
>> +/**
>> + * GVirDomainShutdownFlags:
>> + * @GVIR_DOMAIN_SHUTDOWN_NONE: No flags, hypervisor choice
>> + * @GVIR_DOMAIN_SHUTDOWN_ACPI_POWER_BTN: Send ACPI event
>> + * @GVIR_DOMAIN_SHUTDOWN_GUEST_AGENT: Use guest agent
>> + *
>> + */
>> +typedef enum {
>> +    GVIR_DOMAIN_SHUTDOWN_NONE           = 0,
>
> I was looking again at this patch, and I was wondering why it's not doing
> this instead of using SHUTDOWN_NONE:

The counterpart GVirDomainStartFlags uses _NONE. Is this a "flawed" in
libvirt API? Do we prefer to copy libvirt or do we want consitancy? I
prefer constitancy.

However, DEFAULT was perhaps a better name than NONE for default behaviour.

I would suggest with your patch we add START_DEFAULT, (but keep
START_NONE), for consistancy.

Daniel should now what feels right, so I will follow his opinion

-- 
Marc-André Lureau


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]