All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Fehlig <jfehlig@suse.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "George.Dunlap@citix.com" <George.Dunlap@citix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Rob Hoes <Rob.Hoes@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH] libxl: unconst the event argument to the event_occurs hook.
Date: Mon, 29 Apr 2013 22:24:27 -0600	[thread overview]
Message-ID: <517F477B.6090503@suse.com> (raw)
In-Reply-To: <1367223373.3142.189.camel@zakaz.uk.xensource.com>

Ian Campbell wrote:
>>> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
>>> index 25efa76..ef96bce 100644
>>> --- a/tools/libxl/libxl.h
>>> +++ b/tools/libxl/libxl.h
>>> @@ -273,9 +273,9 @@
>>>  #include <libxl_uuid.h>
>>>  #include <_libxl_list.h>
>>>  
>>> -/* API compatibility. Only 0x040200 is supported at this time. */
>>> +/* API compatibility. */
>>>  #ifdef LIBXL_API_VERSION
>>> -#if LIBXL_API_VERSION != 0x040200
>>> +#if LIBXL_API_VERSION != 0x040200 && LIBXL_API_VERSION != 0x040300
>>>  #error Unknown LIBXL_API_VERSION
>>>  #endif
>>>  #endif
>>>   
>>>       
>> Should this hunk be in a separate patch? It seems to be introducing a
>> new API version :).
>>     
>
> I suppose it could be, or we could argue that this patch is introducing
> the first user of this API version?
>   

Ok.

>   
>>> @@ -308,6 +308,16 @@
>>>   */
>>>  #define LIBXL_HAVE_DEVICE_BACKEND_DOMNAME 1
>>>  
>>> +/*
>>> + * LIBXL_HAVE_NONCONST_EVENT_OCCURS_EVENT_ARG
>>> + *
>>> + * This argument was erroneously "const" in the 4.2 release despite
>>> + * the requirement for the callback to free the event.
>>> + */
>>> +#if LIBXL_API_VERSION != 0x040200
>>>       
>
> Looking at this again today this happens to be true if LIBXL_API_VERSION
> is undefined but I wonder if we ought to explicitly define
> LIBXL_API_VERSION to 0xffffff if the user doesn't supply it?
>   

Ah, good point.  But setting LIBXL_API_VERSION to 0xffffffff if the app
doesn't supply it means the app, which e.g. built fine on 4.2, would no
longer compile on 4.3 right?

Regards,
Jim

  reply	other threads:[~2013-04-30  4:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-26 11:42 [PATCH] libxl: unconst the event argument to the event_occurs hook Ian Campbell
2013-04-26 21:22 ` Jim Fehlig
2013-04-29  8:16   ` Ian Campbell
2013-04-30  4:24     ` Jim Fehlig [this message]
2013-04-30  9:43       ` Ian Campbell
2013-04-30 22:47         ` Jim Fehlig
2013-04-29  8:20   ` Ian Campbell
2013-05-01 10:48   ` [PATCH] libxl: unconst the event argument to the event_occurs hook. [and 1 more messages] Ian Jackson
2013-05-01 12:33     ` Ian Campbell
2013-04-29 10:04 ` [PATCH] libxl: unconst the event argument to the event_occurs hook George Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=517F477B.6090503@suse.com \
    --to=jfehlig@suse.com \
    --cc=George.Dunlap@citix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=Rob.Hoes@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.