Re: [Xen-devel] [RFC PATCH v3 07/24] ARM: NUMA: Add existing ARM numa code under CONFIG_NUMA

[Julien Grall <julien.grall@xxxxxxx>]

Hi Vijay,

On 20/07/17 10:31, Vijay Kilari wrote:
> On Tue, Jul 18, 2017 at 11:36 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
> > Hi Vijay,
> >
> > On 18/07/17 12:41, vijay.kilari@xxxxxxxxx wrote:
> > > From: Vijaya Kumar K <Vijaya.Kumar@xxxxxxxxxx>
> > >
> > > Right now CONFIG_NUMA is not enabled for ARM and
> > > existing code in asm-arm/numa.h is for !CONFIG_NUMA.
> > > Hence put this code under #ifndef CONFIG_NUMA.
> > >
> > > This help to make this changes work when CONFIG_NUMA
> > > is not enabled. Though CONFIG_NUMA is enabled by default,
> > > manually disabling this option is possible and compilation
> > > should go through. Hence kept the these changes under
> > > !CONFIG_NUMA.
> >
> > This is still no true. It is not possible to disable CONFIG_NUMA from the
> > Kconfig unless you hack it (just tried it)...
> >
> > As I said on v2, if you always enable NUMA why should we add code in Xen
> > that get rotten? Either you allow NUMA to be disabled by the user or you
> > drop this code.
> The reason is: The next patch #8, which does the code movement moves
> the generic code to common header file xen/numa.h.
> If we don't put these *existing* defines in asm-arm/numa.h under
> #ifndef CONFIG_NUMA,
> the compilation fails for ARM.
>
> Is it ok to removes these defines under separate patch after enabling
> NUMA config
> at the end of patch series?
>
> Let me know if you have any better approach.
The question here is more, do we want to allow the user disabling NUMA 
(even if it has to be guarded with EXPERT)? You seem to choose the 
approach where NUMA is here by default and can't be disabled.
1) If we decide to let the user configuring NUMA, then this patch is 
valid as it is.
2) If not, then you need a patch drop this code at the end and have a 
word in this commit message explaining this is temporary...
When the question above is answered, you need to do either 1) or 2) 
according to the answer.
Cheers,

--
Julien Grall

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