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@xxxxxxxxx> > To: post@xxxxxxxx > Cc: linux-mips@xxxxxxxxxxxxxx > Subject: Re: [PATCH 0/2] FLATMEM: allow memory to start at pfn != 0 [take > #2] > > Hi, > > On 3/10/07, peter fuerst <post@xxxxxxxx> 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
