CFT: uintmax_t rman

Warner Losh imp at bsdimp.com
Mon Nov 16 17:31:19 UTC 2015


> 
> On Nov 15, 2015, at 9:13 PM, Justin Hibbits <chmeeedalf at gmail.com> wrote:
> 
> (Attempted to send this yesterday, but appears it didn't go through.  Apologies if it really did go through).
> 
> As part of a project getting FreeBSD on the Freescale P5020 SoC, I increased the width of resources, from u_long(32 bits on 32-bit archs, 64 bits on 64-bit archs) to uintmax_t (currently 64 bits on all archs).  I have it working on PowerPC, but have not tested it on any other architecture, I have no other systems to test it with, so I need help.  This passes a tinderbox build.  I need this tested on other archs, the more the better, especially i386, including PAE.
> 
> It should be effectively a no-op on most architectures, especially 64-bit archs, though there were some checks I found in x86 code clamping address checks to under 4GB, commented as necessary purely for rman.  If this isn't the case, and we can't yet handle the checks being removed, they can go in, but that needs testing.  It should apply cleanly to recent head.

I like the idea. There’s nothing offensive enough in the diffs to comment upon here (though I suppose I could see a few spots one could quibble over if one were so inclined).

I wonder, though, why not make its own typedef, even if it is just ‘typedef man_res_t uintmax_t;’ in the rman headers?

Warner


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20151116/fb58441e/attachment.bin>


More information about the freebsd-current mailing list