<br><br><div><span class="gmail_quote">On 7/8/07, <b class="gmail_sendername">Matthew Fluet</b> <<a href="mailto:fluet@tti-c.org">fluet@tti-c.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Is the HW_PAGESIZE sysctl also a size_t? The FreeBSD sysctl man page<br>just says that the type is "integer".</blockquote><div><br>Oh, my change may actually be slightly wrong. The HW_PHYSMEM mib is defined in
<br>/usr/src/sys/kern/kern_mib.c:<br><br>--><br> SYSCTL_PROC(_hw, HW_PHYSMEM, physmem, CTLTYPE_ULONG | CTLFLAG_RD,<br> 0, 0, sysctl_hw_physmem, "LU", "");<br><--<br><br>with a type of CLTYPE_ULONG, which you can find in /usr/src/sys/sys/sysctl.h described as an Unsigned Long. On a 64-bit architecture, this will be a 64-bit value if my memory serves me right with C-conventions and LP64. So rather than a size_t, we may want an unsigned long in FreeBSD land...
<br><br>The HW_PAGESIZE is also right there<br>--><br>SYSCTL_INT(_hw, HW_PAGESIZE, pagesize, CTLFLAG_RD,<br> 0, PAGE_SIZE, "System memory page size");<br><--<br><br>SYSCTL_INT is a macro defined in /usr/src/sys/sys/sysctl.h setting CTLTYPE_INT which is an 'int' in C-conventions. FreeBSD would serve us better had they documented this in their man-page in my opinion.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Also, the NetBSD man page seems to suggest that a separate physmem64<br>control is used to fetch the size of RAM, while physmem is guaranteed to
<br>be 32-bits:<br> <a href="http://netbsd.gw.com/cgi-bin/man-cgi?sysctl+7+NetBSD-current">http://netbsd.gw.com/cgi-bin/man-cgi?sysctl+7+NetBSD-current</a></blockquote><div><br>The sysctls are different among the BSD-derived systems. There may be some simarity between NetBSD and OpenBSD due to their heritage (OpenBSD stems from NetBSD). It does mean, though, that we might want to handle the sysctls on a per-platform basis more than we do right now. I am not sure what is the best approach to take.
<br><br></div><br></div>