From: William Lee Irwin III <wli@holomorphy.com>
To: Ian Pratt <Ian.Pratt@cl.cam.ac.uk>
Cc: Andrew Morton <akpm@osdl.org>,
Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>,
Keir.Fraser@cl.cam.ac.uk, haveblue@us.ibm.com,
linux-kernel@vger.kernel.org, Christian.Limpach@cl.cam.ac.uk
Subject: Re: [patch 2] Xen core patch : arch_free_page return value
Date: Thu, 18 Nov 2004 04:57:35 -0800 [thread overview]
Message-ID: <20041118125735.GD2268@holomorphy.com> (raw)
In-Reply-To: <E1CUlkn-0007sb-00@mta1.cl.cam.ac.uk>
On Thu, Nov 18, 2004 at 12:51:12PM +0000, Ian Pratt wrote:
> 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.
On some architectures it takes 5 arguments, and on others, 6.
It won't compile everywhere without an #ifdef.
-- wli
next prev parent reply other threads:[~2004-11-18 12:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-18 10:05 [patch 2] Xen core patch : arch_free_page return value Ian Pratt
2004-11-18 10:14 ` Andrew Morton
2004-11-18 10:18 ` Keir Fraser
2004-11-18 12:39 ` William Lee Irwin III
2004-11-18 10:36 ` William Lee Irwin III
2004-11-18 12:51 ` Ian Pratt
2004-11-18 12:57 ` William Lee Irwin III [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-11-17 23:48 Ian Pratt
2004-11-18 1:04 ` Dave Hansen
2004-11-18 1:19 ` Ian Pratt
2004-11-18 1:26 ` Dave Hansen
2004-11-18 8:35 ` Keir Fraser
2004-11-18 9:17 ` Andrew Morton
2004-11-18 5:08 ` Jeff Dike
2004-11-18 3:09 ` Andrew Morton
2004-11-18 6:54 ` Jeff Dike
2004-11-18 4:57 ` Andrew Morton
2004-11-18 8:37 ` Mitchell Blank Jr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041118125735.GD2268@holomorphy.com \
--to=wli@holomorphy.com \
--cc=Christian.Limpach@cl.cam.ac.uk \
--cc=Ian.Pratt@cl.cam.ac.uk \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=akpm@osdl.org \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m+Ian.Pratt@cl.cam.ac.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.