Messages in this thread | | | Date | Thu, 18 Nov 2004 04:39:21 -0800 | From | William Lee Irwin III <> | Subject | Re: [patch 2] Xen core patch : arch_free_page return value |
| |
"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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |