> -----Original Message-----
> From: Andrew Cooper <andrew.coop...@citrix.com>
> Sent: 30 July 2020 18:34
> To: p...@xen.org; 'Xen-devel' <xen-devel@lists.xenproject.org>
> Cc: 'Jan Beulich' <jbeul...@suse.com>; 'Wei Liu' <w...@xen.org>; 'Roger Pau 
> Monné'
> <roger....@citrix.com>; 'Stefano Stabellini' <sstabell...@kernel.org>; 
> 'Julien Grall'
> <jul...@xen.org>; 'Volodymyr Babchuk' <volodymyr_babc...@epam.com>; 'Michał 
> Leszczyński'
> <michal.leszczyn...@cert.pl>; 'Hubert Jasudowicz' <hubert.jasudow...@cert.pl>
> Subject: Re: [PATCH 1/5] xen/memory: Introduce CONFIG_ARCH_ACQUIRE_RESOURCE
> 
> On 30/07/2020 09:02, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Andrew Cooper <andrew.coop...@citrix.com>
> >> Sent: 28 July 2020 12:37
> >> To: Xen-devel <xen-devel@lists.xenproject.org>
> >> Cc: Andrew Cooper <andrew.coop...@citrix.com>; Jan Beulich 
> >> <jbeul...@suse.com>; Wei Liu
> <w...@xen.org>;
> >> Roger Pau Monné <roger....@citrix.com>; Stefano Stabellini 
> >> <sstabell...@kernel.org>; Julien Grall
> >> <jul...@xen.org>; Volodymyr Babchuk <volodymyr_babc...@epam.com>; Paul 
> >> Durrant <p...@xen.org>;
> Michał
> >> Leszczyński <michal.leszczyn...@cert.pl>; Hubert Jasudowicz 
> >> <hubert.jasudow...@cert.pl>
> >> Subject: [PATCH 1/5] xen/memory: Introduce CONFIG_ARCH_ACQUIRE_RESOURCE
> >>
> >> New architectures shouldn't be forced to implement no-op stubs for unused
> >> functionality.
> >>
> >> Introduce CONFIG_ARCH_ACQUIRE_RESOURCE which can be opted in to, and 
> >> provide
> >> compatibility logic in xen/mm.h
> >>
> >> No functional change.
> > Code-wise, it looks fine, so...
> >
> > Reviewed-by: Paul Durrant <p...@xen.org>
> 
> Thanks,
> 
> >
> > ...but ...
> >
> >> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
> >> ---
> >> CC: Jan Beulich <jbeul...@suse.com>
> >> CC: Wei Liu <w...@xen.org>
> >> CC: Roger Pau Monné <roger....@citrix.com>
> >> CC: Stefano Stabellini <sstabell...@kernel.org>
> >> CC: Julien Grall <jul...@xen.org>
> >> CC: Volodymyr Babchuk <volodymyr_babc...@epam.com>
> >> CC: Paul Durrant <p...@xen.org>
> >> CC: Michał Leszczyński <michal.leszczyn...@cert.pl>
> >> CC: Hubert Jasudowicz <hubert.jasudow...@cert.pl>
> >> ---
> >>  xen/arch/x86/Kconfig     | 1 +
> >>  xen/common/Kconfig       | 3 +++
> >>  xen/include/asm-arm/mm.h | 8 --------
> >>  xen/include/xen/mm.h     | 9 +++++++++
> >>  4 files changed, 13 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> >> index a636a4bb1e..e7644a0a9d 100644
> >> --- a/xen/arch/x86/Kconfig
> >> +++ b/xen/arch/x86/Kconfig
> >> @@ -6,6 +6,7 @@ config X86
> >>    select ACPI
> >>    select ACPI_LEGACY_TABLES_LOOKUP
> >>    select ARCH_SUPPORTS_INT128
> >> +  select ARCH_ACQUIRE_RESOURCE
> > ... I do wonder whether 'HAS_ACQUIRE_RESOURCE' is a better and more 
> > descriptive name.
> 
> We don't have a coherent policy for how to categorise these things.  I
> can change the name if you insist, but I'm not sure it makes a useful
> difference.
> 

Ok, it's fine. My R-b stands.

  Paul

> ~Andrew


Reply via email to