Messages in this thread | | | Subject | Re: [patch 2] Xen core patch : arch_free_page return value | Date | Thu, 18 Nov 2004 12:51:12 +0000 | From | Ian Pratt <> |
| |
> On Thu, Nov 18, 2004 at 02:14:19AM -0800, Andrew Morton 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. > > Sorry for stepping in so late. io_remap_page_range() has an > architecture-specific calling convention. It can't be used in code > shared across where the calling conventions differ until that's > resolved (which I intend to do, though I'm not going to stop anyone > from doing it before I get around to it).
Having pulled the latest snapshot, it's good to see that remap_pfn_range has cleaned things up a bit. However, it doesn't solve our problem.
In arch xen we need to use a different function for mapping MMIO or BIOS pages, which is the /dev/mem behaviour we need to support.
I'm not sure we can do this without changing the call in mem.c, at least not without adding an extra hook inside remap_pfn_range that allows us to use an alternative to set_pte e.g. slow_set_pte that tries to figure out whether the pfn is real memory or not. Personally I think the mem.c #ifdef is cleaner and more robust.
I'm not sure I understand the issue about io_remap_page_range having an architecture-specific calling convention. Please can you enlighten me.
Thanks, Ian
- 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/
| |