On Mon, 12 Mar 2007, Franck Bui-Huu wrote:
> Date: Mon, 12 Mar 2007 10:47:01 +0100
> From: Franck Bui-Huu <firstname.lastname@example.org>
> To: email@example.com
> Cc: firstname.lastname@example.org
> Subject: Re: [PATCH 0/2] FLATMEM: allow memory to start at pfn != 0 [take
> On 3/10/07, peter fuerst <email@example.com> wrote:
> > 3) The page_offset adjustment may force fixes in other, not yet blown up,
> > places (pmd_phys() cried out lately...).
> Not really fair. It crashed lately because until now I was the only
May be, so i apologize.
> one to use it. And unfortunately I failed to give back this change to
> Ralf's tree.
You see the problem. Any occurrence of PAGE_OFFSET must be checked.
> BUT, note that the root cause of this bug is that we did _plain_
> address translation instead of using dedicated macro.
> So I would say that this patch helps to fix these buggy places.
Sure, a dedicated macro or function is the correct way to handle all
the kernel-addresses. Moreover it would be desirable, if this macro
really could be used throughout the kernel, e.g. by drivers, handling
any reasonable kernel-address, which isn't possible in the page_offset
> > What can PHYS_OFFSET achieve here - besides obfuscating ?
> > Are there future uses for it, that justify the contortions ?
> How do you deal with fancy cases such as physical memory starting at
> 0x20000000 for example ?
With XKPHYS and exactly this offset ;-)
To be serious again:
O.K. i see the future use is to support TLB-mapped 32bit kernels.
In this case, with respect to unmapped kernels, the min_low_pfn stuff
should be decoupled from the PHYS_OFFSET setting, to let the unmapped
kernels keep it zero and benefit from memory savings though.
Otherwise, for each different non-zero PHYS_OFFSET, there must be an
accordingly adjusted PAGE_OFFSET (the CKSEG0 part in __pa_page_offset
is still to be prepared for this).