Hi!
On Mon, 12 Mar 2007, Franck Bui-Huu wrote:
> Date: Mon, 12 Mar 2007 10:47:01 +0100
> From: Franck Bui-Huu <vagabon.xyz@gmail.com>
> To: post@pfrst.de
> Cc: linux-mips@linux-mips.org
> Subject: Re: [PATCH 0/2] FLATMEM: allow memory to start at pfn != 0 [take
> #2]
>
> Hi,
>
> On 3/10/07, peter fuerst <post@pfrst.de> 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
scheme anyway.
>
> > 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).
>
> --
> Franck
>
>
kind regards
peter
|