svn commit: r297000 - in head: . sys/arm/xscale/ixp425 sys/arm/xscale/pxa sys/compat/ndis sys/dev/acpica sys/dev/advansys sys/dev/atkbdc sys/dev/bxe sys/dev/cardbus sys/dev/ctau sys/dev/ed sys/dev/...

[John Baldwin]

On Friday, March 18, 2016 01:28:41 AM Justin Hibbits wrote:
> Author: jhibbits
> Date: Fri Mar 18 01:28:41 2016
> New Revision: 297000
> URL: https://svnweb.freebsd.org/changeset/base/297000
> 
> Log:
>   Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.
>   
>   On some architectures, u_long isn't large enough for resource definitions.
>   Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but
>   type `long' is only 32-bit.  This extends rman's resources to uintmax_t.  With
>   this change, any resource can feasibly be placed anywhere in physical memory
>   (within the constraints of the driver).
>   
>   Why uintmax_t and not something machine dependent, or uint64_t?  Though it's
>   possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on
>   32-bit architectures.  64-bit architectures should have plenty of RAM to absorb
>   the increase on resource sizes if and when this occurs, and the number of
>   resources on memory-constrained systems should be sufficiently small as to not
>   pose a drastic overhead.  That being said, uintmax_t was chosen for source
>   clarity.  If it's specified as uint64_t, all printf()-like calls would either
>   need casts to uintmax_t, or be littered with PRI*64 macros.  Casts to uintmax_t
>   aren't horrible, but it would also bake into the API for
>   resource_list_print_type() either a hidden assumption that entries get cast to
>   uintmax_t for printing, or these calls would need the PRI*64 macros.  Since
>   source code is meant to be read more often than written, I chose the clearest
>   path of simply using uintmax_t.
>   
>   Tested on a PowerPC p5020-based board, which places all device resources in
>   0xfxxxxxxxx, and has 8GB RAM.
>   Regression tested on qemu-system-i386
>   Regression tested on qemu-system-mips (malta profile)
>   
>   Tested PAE and devinfo on virtualbox (live CD)
>   
>   Special thanks to bz for his testing on ARM.
>   
>   Reviewed By: bz, jhb (previous)
>   Relnotes:	Yes
>   Sponsored by:	Alex Perez/Inertial Computing
>   Differential Revision: https://reviews.freebsd.org/D4544

Thank you for chasing this down to completion.  It removes quite a few hacks
from the PAE case.  Thank you also for being patient when I asked you to split
the changes up, rearrange things, etc. :)

-- 
John Baldwin