On Mon, 16 Nov 2015, Warner Losh wrote:
> > On Nov 15, 2015, at 9:13 PM, Justin Hibbits <chmeeed...@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
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"