On Mon, 16 Nov 2015, Warner Losh wrote: > > > > 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? Channeling my inner bde (maybe?), the typedef is probably helpful, but uintmax_t seems less so. uintmax_t has no guaranteed ABI, so a fixed-width type like uint64_t seems beter, assuming that uintmax_t is currently uint64_t everywhere (which I think is the case but did not verify). -BenReceived on Mon Nov 16 2015 - 23:31:09 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:01 UTC