From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Roland Dreier <rdreier@cisco.com>
Cc: linuxppc-dev@ozlabs.org, Joachim Fenkes <fenkes@de.ibm.com>,
Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH] Allow drivers to map individual 4k pages to userspace
Date: Wed, 04 Apr 2007 14:43:50 +1000 [thread overview]
Message-ID: <1175661830.30879.71.camel@localhost.localdomain> (raw)
In-Reply-To: <adamz1odbpr.fsf@cisco.com>
On Tue, 2007-04-03 at 21:07 -0700, Roland Dreier wrote:
> > It's somewhat architected. I doubt there will ever be a processor that
> > can have an eHCA and doesn't support that trick. The thing is, eHCA is
> > platform specific, so the remap_4k_pfn would have to be called by driver
> > specific code, but that's not a problem since that driver will only ever
> > be used on those platforms that support that call.
>
> If I'm going off on something irrelevant, just tell me. But is there
> a chance that you would want to build a kernel that can boot on both a
> platform that has eHCA, and also on some other platform that cannot
> support remap_4k_pfn? If so does this approach cause problems?
As long as remap_4k_pfn() is only called on the platform that supports
it, it's fine... and if we ever end up having such platforms (we don't
at the moment, remap_4k_pfn() is basically a forced 4K fallback which is
always possible in a machine running a 64K base page kernel), we'll make
it fail at runtime. Again, as long as it's called only by the eHCA
driver, we are pretty certain it will only ever be called on plaforms
where it makes sense.
Ben.
next prev parent reply other threads:[~2007-04-04 4:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-03 11:24 [PATCH] Allow drivers to map individual 4k pages to userspace Paul Mackerras
2007-04-04 2:34 ` Roland Dreier
2007-04-04 3:23 ` Benjamin Herrenschmidt
2007-04-04 4:07 ` Roland Dreier
2007-04-04 4:43 ` Benjamin Herrenschmidt [this message]
2007-04-04 5:14 ` Paul Mackerras
2007-04-04 4:41 ` Paul Mackerras
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=1175661830.30879.71.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=fenkes@de.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=rdreier@cisco.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).