From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tamas Lengyel Subject: Re: Issues regarding "mem_access: Add helper API to setup ring and enable mem_access" Date: Mon, 30 Jun 2014 16:49:54 +0200 Message-ID: References: <1403882455.3169.72.camel@kazak.uk.xensource.com> <21425.23379.795171.801716@mariner.uk.xensource.com> <1404132276.14488.41.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1461594083009982013==" Return-path: In-Reply-To: <1404132276.14488.41.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Aravindh Puthiyaparambil , Ian Jackson , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============1461594083009982013== Content-Type: multipart/alternative; boundary=047d7bf0cad4a52c8804fd0ec529 --047d7bf0cad4a52c8804fd0ec529 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 30, 2014 at 2:44 PM, Ian Campbell 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 --047d7bf0cad4a52c8804fd0ec529 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 30, 2014 at 2:44 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
On Mon, 2= 014-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""): > >
> > =C2=A0 =C2=A0 > Now with this function being reintroduced, it = becomes more complicated
> > =C2=A0 =C2=A0 > to determine which version of the mem_access A= PI does Xen actually
> > =C2=A0 =C2=A0 > provide. A #define indicating mem_access API v= ersion would nicely
> > =C2=A0 =C2=A0 > overcome this issue, or =C2=A0naming xc_mem_ev= ent_enable something else.
> >
> > =C2=A0 =C2=A0 Doesn't configure support checking for function= s with a given prototype?
> >
> > It does but in a very hacky way, essentially trying to compile co= de where the
> > function is being called with different prototypes. We can work a= round it but a
> > clean solution would be preferred at some point.
>
> I agree with your criticism, TBH. =C2=A0Aravindh/Ian, can we rename th= is
> 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

/**
=C2=A0* me= m_event operations. Internal use only.
=C2=A0*/

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

Tamas
--047d7bf0cad4a52c8804fd0ec529-- --===============1461594083009982013== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1461594083009982013==--