Re: Why *not* rmap, anyway?

[Daniel Phillips <phillips@bonn-fries.net>]

On Wednesday 08 May 2002 16:43, Rik van Riel wrote:
> On Wed, 8 May 2002, Daniel Phillips wrote:
> 
> > To make this concrete, what would copy_page_range look like, using this
> > mechanism?
> 
> Or maybe copy_page_range should be behind this mechanism and
> modify the data structures directly ?

It already modifies the data structures directly.  You're proposing that 
copy_page_range should be per_arch?

> Remember that the goal is not to abstract out all of the VM,
> the goal is to make _most_ of the VM more readable and maintainable.

remap_page_range has the same problem.  So which of the bulk memory 
operations actually gets cleaner?

If the answer to 'can the proposed api handle copy_page_range?' is 'no', then 
it's not a very interesting api.  And by 'handling' I don't mean 'make it 
per-arch', that's going backwards.

-- 
Daniel
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/