On Mon, Jun 30, 2014 at 2:44 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:

On Mon, 2014-06-30 at 13:42 +0100, Ian Jackson wrote:
> Tamas Lengyel writes ("Re: [Xen-devel] Issues regarding "mem_access: Add helper API to setup ring and enable mem_access""):
> >
> > > Now with this function being reintroduced, it becomes more complicated
> > > to determine which version of the mem_access API does Xen actually
> > > provide. A #define indicating mem_access API version would nicely
> > > overcome this issue, or naming xc_mem_event_enable something else.
> >
> > Doesn't configure support checking for functions with a given prototype?
> >
> > It does but in a very hacky way, essentially trying to compile code where the
> > function is being called with different prototypes. We can work around it but a
> > clean solution would be preferred at some point.
>
> I agree with your criticism, TBH. Aravindh/Ian, can we rename this
> function ?

I have no objection to some other name.

A question regarding renaming the xc_mem_event_enable function. The public xenctrl.h clearly says

/**
* mem_event operations. Internal use only.
*/

There are only three of these, xc_mem_event_control, xc_mem_event_memop and xc_mem_event_enable. Wouldn't it make more sense to just exclude these functions from the public header and move them to xc_private.h? Why have internal functions in the public header?

Tamas