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

[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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/