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