All of lore.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>,
	Keir.Fraser@cl.cam.ac.uk, haveblue@us.ibm.com,
	Ian.Pratt@cl.cam.ac.uk, 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 02:36:20 -0800	[thread overview]
Message-ID: <20041118103620.GC3217@holomorphy.com> (raw)
In-Reply-To: <20041118021419.0c0d1dad.akpm@osdl.org>

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).

As drivers/char/mem.c is shared across all architectures, using
io_remap_page_range() there now is unsound and some other method to
accomplish whatever it does beyond remap_pfn_range() must be found
unless the io_remap_page_range() calling convention is resolved first.


-- wli

  parent reply	other threads:[~2004-11-18 10:42 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 [this message]
2004-11-18 12:51     ` Ian Pratt
2004-11-18 12:57       ` William Lee Irwin III
  -- 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=20041118103620.GC3217@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.