On 29.11.2012 00:14, Bruce Evans wrote:
On Wed, 28 Nov 2012, Andre Oppermann wrote:
On 28.11.2012 18:37, Alan Cox wrote:
I'm pretty sure that the "realmem" calculation is going to overflow on
i386/PAE, where the number of bytes of physical memory is greater than
the type long can represent.
Right. long == int on i386/PAE, not LP64. Is uint64_t the correct type
to use to catch that?
No. 2**63-1 bytes of physical memory might be enough for anyone, but
more than that is is useful for virtual memory, and there is no need
to ensure that P128 will be broken when it exists.
I would just use sizes in pages for everything so that 32-bit u_ints
are enough. Although this may break before P128 exists.
Pages is not optimal as it would complicate the translations to the
different mbuf sizes which are not necessarily integer multiple of pages.
Otherwise, uintmax_t should be used. Sloppy code can also depend on
uintmax_t being "infinitely" large, so that multiplications by small
scale factors don't overflow (use the more natural 'foo = bar * 3 / 4;'
instead of 'foo = bar / 4 * 3;', but this can still overflow if bar
is user input (say a tunable) that is not already limited enough.
In the other patch I already sent to you I've used quad_t because we
already have an existing TUNABLE_QUAD_FETCH macro for it. It also
more natural for people to specify a memory related number in raw
bytes rather than pages (which are 8k on IA64 IIRC).
vm_paddr_t could be used for physical memory sizes, but might be too
small or too large for virtual memory sizes, so using it would often
give the same bloat as using uintmax_t, and more complications than
using either u_int or uintmax_t for everything.
--
Andre
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
