Re: [PAE support] Types + cosmetic fixes

[christos%astron.com@localhost (Christos Zoulas)]

In article <8bc7849fd8c20cbbac9b3b29893ad839@localhost>,
Jean-Yves Migeon  <jeanyves.migeon%free.fr@localhost> 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)
>- "unsigned long" cannot be considered as a physical address anymore
>
>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?),
>- 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.
>
>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; and don't forget the drm code which makes assumptions about
vsize_t... What is vsize_t now?

christos