Why is TUNABLE_INT discouraged?
Garrett Cooper
gcooper at FreeBSD.org
Sat Aug 7 22:19:38 UTC 2010
2010/8/7 Dag-Erling Smørgrav <des at des.no>:
> Ivan Voras <ivoras at freebsd.org> writes:
>> Ok, but still - if the underlying value really is declared as "int",
>> doesn't it make perfect sense to have something like TUNABLE_INT for it?
>
> Perhaps. I don't remember all the details; I can't find a discussion in
> the list archives (other than me announcing the change in response to a
> bug report), but there must have been one, either on IRC or in Karlsruhe.
> In any case, I never removed TUNABLE_INT(), so...
It does matter for integers on 64-bit vs 32-bit architectures though,
right (feel free to ignore the second i386 value for _limits.h... it
was a hack for gcc according to the comment)?
$ egrep -nr '#define[[:space:]]+__LONG_MAX' amd64/include/
i386/include/ | grep -v svn
amd64/include/_limits.h:63:#define __LONG_MAX 0x7fffffffffffffffL /*
max for a long */
i386/include/_limits.h:65:#define __LONG_MAX 0x7fffffffffffffffL
i386/include/_limits.h:69:#define __LONG_MAX 0x7fffffffL /* max value
for a long */
$ egrep -nr '#define[[:space:]]+__INT_MAX' amd64/include/
i386/include/ | grep -v svn
amd64/include/_limits.h:59:#define __INT_MAX 0x7fffffff /* max value
for an int */
i386/include/_limits.h:59:#define __INT_MAX 0x7fffffff /* max value
for an int */
I was originally asking because I didn't have the background to know
why a TUNABLE_UINT set of macros didn't exist.
Thanks,
-Garrett
More information about the freebsd-hackers
mailing list