From: "H. Peter Anvin" <hpa@zytor.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: "Huang, Ying" <ying.huang@intel.com>,
venkatesh.pallipadi@intel.com, akpm@linux-foundation.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Andi Kleen <ak@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm 0/3] i386 boot: replace boot_ioremap with enhanced bt_ioremap
Date: Tue, 15 Jan 2008 08:38:35 -0500 [thread overview]
Message-ID: <478CB75B.70503@zytor.com> (raw)
In-Reply-To: <20080115133942.GI7025@elte.hu>
Ingo Molnar wrote:
> * H. Peter Anvin <hpa@zytor.com> wrote:
>
>> I did a quick scan over the patchset (not quite awake yet, so I may
>> very well have missed something), but it looks like EFI (again!) is
>> the only user of ioremapping before paging_init(). This makes me
>> wonder if that code can't be restructured so that isn't necessary.
>
> i think that in general making access to unmapped memory a bit easier is
> generally a good robustness idea as ACPI could be impacted by it as
> well.
>
> Fundamentally, paging_init() has obvious dependency on "figuring out the
> memory setup" of the box, and "figuring out the memory setup" means
> interpreting various data structures passed in by the BIOS - some of
> which might be in not yet mapped areas or iommu areas (if we have to do
> some early quirk). So having a robust implementation of ioremap_early()
> sounds like a definitive plus.
>
Fair enough. If it's generally useful, I certainly have no objections.
-hpa
next prev parent reply other threads:[~2008-01-15 13:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-15 5:45 [PATCH -mm 0/3] i386 boot: replace boot_ioremap with enhanced bt_ioremap Huang, Ying
2008-01-15 8:44 ` Ingo Molnar
2008-01-15 9:48 ` Huang, Ying
2008-01-15 12:52 ` H. Peter Anvin
2008-01-15 13:39 ` Ingo Molnar
2008-01-15 13:38 ` H. Peter Anvin [this message]
2008-01-15 13:36 ` Ingo Molnar
2008-01-16 2:51 ` [PATCH -mm 0/3] i386 boot: replace boot_ioremap with enhancedbt_ioremap Pallipadi, Venkatesh
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=478CB75B.70503@zytor.com \
--to=hpa@zytor.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=venkatesh.pallipadi@intel.com \
--cc=ying.huang@intel.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 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.