On Mon, Feb 22, 2010 at 10:25:35AM +0100, Jean-Yves Migeon wrote: > > Hi lists, > > Before asking for review of the patch regarding PAE support inside native > i386 kernel (inspired from jmorse@ work from a few weeks ago), I would like > to commit these beforehand ([1] & [2]). I made them separate because they > are not for PAE support "per-see." > > They are mostly types + cosmetic fixes. As some of you may now, introducing > PAE affects the x86 paradigm inside NetBSD a bit: > - sizeof paddr_t != sizeof vaddr_t (64 bits for paddr_t, 32 bits for > vaddr_t)
We already gave platorms like that (or had - the sh5 port). we already have it for Xen ... So no major problems with this I guess. > - "unsigned long" cannot be considered as a physical address anymore It should not in the first place :) > > This affect a couple of printfs(), printk() and debugging messages, as well > as some variables types used inside x86 pmap [1]. > > Second small patch [2] contains fixes regarding UVM: > - RLIMIT_RSS which is now set to VM_MAXUSER_ADDRESS (shouldn't it be set to > MIN(VM_MAXUSER_ADDRESS, ptoa(uvmexp.free) instead?), I think it should be MIN(VM_MAXUSER_ADDRESS, ptoa(uvmexp.free). Otherwise it's a change in behavior not related to i386PAE. > - ptoa => ctob use (to avoid vaddr_t casts, which might be bad for systems > with total RAM > 4GB) > - a small fix inside AGP heuristics to avoid masking high order bits > > Compile tested for ALL, GENERIC, XEN3 kernels for i386, and GENERIC, XEN3* > for amd64. Looks good. > > In case someone wonders, if PAE is added as default option for ALL, more > fixes will be needed in some drivers under sys/dev/ (paddr_t vs unsigned > long issues). Question is: should it be added to ALL for additional checks? I think so. Such issues should be fixed in MI code anyway. paddr_t != unsigned long is something we want to support. -- Manuel Bouyer <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --