Re: [Xen-devel] Issues regarding "mem_access: Add helper API to setup ring and enable mem_access"

[Tamas Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

On Mon, Jun 30, 2014 at 2:44 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel