From owner-svn-src-all@freebsd.org Fri Mar 18 18:05:13 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2898CAD4D41; Fri, 18 Mar 2016 18:05:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 08464104B; Fri, 18 Mar 2016 18:05:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 19C91B93A; Fri, 18 Mar 2016 14:05:12 -0400 (EDT) From: John Baldwin To: Justin Hibbits Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: 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/... Date: Fri, 18 Mar 2016 10:49:45 -0700 Message-ID: <2148463.8F4WoXScuZ@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <201603180128.u2I1SfaM039505@repo.freebsd.org> References: <201603180128.u2I1SfaM039505@repo.freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 18 Mar 2016 14:05:12 -0400 (EDT) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 18:05:13 -0000 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