Re: [patch 2] Xen core patch : arch_free_page return value

[William Lee Irwin III <wli@holomorphy.com>]

"Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> wrote:
>> Just send 'em to linux-kernel first-up and cc everyone else.  That way you
>> avoid duplication of effort and everyone is on the same page.
>> I'm still struggling to understand the rationale behind the mem.c change
>> btw.  io_remap_page_range() _is_ remap_page_range() (or, now,
>> remap_pfn_range()) on x86.  So whatever the patch is supposed to be doing,
>> it's a no-op.

On Thu, Nov 18, 2004 at 10:18:28AM +0000, Keir Fraser wrote:
> We need to sync up to the current BK tree and see what needs to be
> done. If remap_pfn_range() is arch-dep and only used in contexts where
> you want to remap real physical address ranges (not "kernel physical"
> address ranges) then we can reimplement remap_pfn_range() and remove
> that CONFIG_XEN part of mem.c.

It is not so. It uses pfn_to_page() etc. which means it must be aligned
with kernel physical addresses. Xen's requirement is highly unusual. It
may unfortunately merit another #ifdef in drivers/char/mem.c, as using
io_remap_page_range() without such will break some architecture.


-- wli