[CRIU] [RESEND PATCH v3 1/2] mm: Introducing arch_remap hook

Andrew Morton akpm at linux-foundation.org
Tue Apr 14 12:38:53 PDT 2015


On Tue, 14 Apr 2015 11:26:13 +0200 Laurent Dufour <ldufour at linux.vnet.ibm.com> wrote:

> > Do away with __HAVE_ARCH_REMAP and do it like this:
> > 
> > arch/x/include/asm/y.h:
> > 
> > 	extern void arch_remap(...);
> > 	#define arch_remap arch_remap
> > 
> > include/linux/z.h:
> > 
> > 	#include <asm/y.h>
> > 
> > 	#ifndef arch_remap
> > 	static inline void arch_remap(...) { }
> > 	#define arch_remap arch_remap
> > 	#endif
> 
> Hi Andrew,
> 
> I like your idea, but I can't find any good candidate for <asm/y.h> and
> <linux/z.h>.
> 
> I tried with <linux/mm.h> and <asm/mmu_context.h> but
> <asm/mmu_context.h> is already including <linux/mm.h>.
> 
> Do you have any suggestion ?
> 
> Another option could be to do it like the actual arch_unmap() in
> <asm-generic/mm_hooks.h> but this is the opposite of your idea, and Ingo
> was not comfortable with this idea due to the impact of the other
> architectures.

I don't see any appropriate header files for this.  mman.h is kinda
close.

So we create new header files, that's not a problem.  I'm torn between

a) include/linux/mm-arch-hooks.h (and 31
   arch/X/include/asm/mm-arch-hooks.h).  Mandate: mm stuff which can be
   overridded by arch

versus

b) include/linux/mremap.h (+31), with a narrower mandate.


This comes up fairly regularly so I suspect a) is better.  We'll add
things to it over time, and various bits of existing ad-hackery can be
moved over as cleanups.



More information about the CRIU mailing list