> -----Original Message-----
> From: Juergen Gross <jgr...@suse.com>
> Sent: Thursday, May 19, 2022 10:31 AM
> To: Lengyel, Tamas <tamas.leng...@intel.com>; xen-
> de...@lists.xenproject.org
> Cc: Wei Liu <w...@xen.org>; Anthony PERARD <anthony.per...@citrix.com>;
> Cooper, Andrew <andrew.coop...@citrix.com>
> Subject: Re: [PATCH] tools/libs/ctrl: add and export xc_memory_op
> 
> On 19.05.22 15:59, Lengyel, Tamas wrote:
> >
> >
> >> -----Original Message-----
> >> From: Xen-devel <xen-devel-boun...@lists.xenproject.org> On Behalf Of
> >> Juergen Gross
> >> Sent: Thursday, May 19, 2022 9:33 AM
> >> To: Lengyel, Tamas <tamas.leng...@intel.com>;
> >> xen-devel@lists.xenproject.org
> >> Cc: Wei Liu <w...@xen.org>; Anthony PERARD
> <anthony.per...@citrix.com>;
> >> Cooper, Andrew <andrew.coop...@citrix.com>
> >> Subject: Re: [PATCH] tools/libs/ctrl: add and export xc_memory_op
> >>
> >> On 19.05.22 15:27, Tamas K Lengyel wrote:
> >>> Add and export xc_memory_op so that do_memory_op can be used by
> >>> tools linking with libxc. This is effectively in the same spirit as
> >>> the existing xc_domctl and xc_sysctl functions, which are already
> exported.
> >>>
> >>> In this patch we move do_memory_op into xc_private.h as a static
> >>> inline function and convert its 'cmd' input from int to unsigned int
> >>> to accurately reflect what the hypervisor expects. No other changes
> >>> are made
> >> to the function.
> >>>
> >>> Signed-off-by: Tamas K Lengyel <tamas.leng...@intel.com>
> >>> ---
> >>>    tools/include/xenctrl.h      |  1 +
> >>>    tools/libs/ctrl/xc_private.c | 63 +++---------------------------------
> >>>    tools/libs/ctrl/xc_private.h | 58 ++++++++++++++++++++++++++++++++-
> >>>    3 files changed, 63 insertions(+), 59 deletions(-)
> >>>
> >>> diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h index
> >>> 95bd5eca67..484e354412 100644
> >>> --- a/tools/include/xenctrl.h
> >>> +++ b/tools/include/xenctrl.h
> >>> @@ -1597,6 +1597,7 @@ int xc_vmtrace_set_option(xc_interface *xch,
> >>> uint32_t domid,
> >>>
> >>>    int xc_domctl(xc_interface *xch, struct xen_domctl *domctl);
> >>>    int xc_sysctl(xc_interface *xch, struct xen_sysctl *sysctl);
> >>> +long xc_memory_op(xc_interface *xch, unsigned int cmd, void *arg,
> >>> +size_t len);
> >>>
> >>>    int xc_version(xc_interface *xch, int cmd, void *arg);
> >>>
> >>> diff --git a/tools/libs/ctrl/xc_private.c
> >>> b/tools/libs/ctrl/xc_private.c index c0422662f0..6a247d2b1f 100644
> >>> --- a/tools/libs/ctrl/xc_private.c
> >>> +++ b/tools/libs/ctrl/xc_private.c
> >>> @@ -326,64 +326,6 @@ int xc_flush_mmu_updates(xc_interface *xch,
> >>> struct
> >> xc_mmu *mmu)
> >>>        return flush_mmu_updates(xch, mmu);
> >>>    }
> >>>
> >>> -long do_memory_op(xc_interface *xch, int cmd, void *arg, size_t
> >>> len)
> >>
> >> Why don't you just rename this function and modify the users to use
> >> the new name?
> >
> > For two reasons:
> > 1) having the do_memory_op as a static inline is consistent with how
> do_domctl and do_sysctl are implemented, so logically that's what I would
> expect to see for the memory_op hypercall as well.
> 
> It is much more complicated than the do_domctl and do_sysctl inlines.
> 
> Additionally it is being used by libxenguest, so making it an inline would
> expose lots of libxenctrl internals to libxenguest.
> 
> > 2) the patch itself is cleaner because there is no churn in all the files 
> > that
> previously called do_memory_op.
> 
> OTOH all callers are in Xen, so its no deal to change those.

I'm fine with going the pure rename route  if that's what's preferred.

Tamas

Reply via email to