Re: Issues regarding "mem_access: Add helper API to setup ring and enable mem_access"

[Tamas Lengyel <tamas.lengyel@zentific.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1482 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 2064 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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