Why is TUNABLE_INT discouraged?

[M. Warner Losh]

In message: <20100808130624.GB40928 at sandvine.com>
            Ed Maste <emaste at FreeBSD.org> writes:
: On Sun, Aug 08, 2010 at 01:30:19AM +0200, Ivan Voras wrote:
: 
: > 2010/8/8 Dag-Erling Sm??rgrav <des at des.no>:
: > > Garrett Cooper <gcooper at FreeBSD.org> writes:
: > >> Dag-Erling Sm??rgrav <des at des.no> writes:
: > >> > 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
: > >
: > > Not sure what you mean. ??The original issue was that someone had used
: > > TUNABLE_INT() for something that was actually a memory address. ??I
: > > changed it to TUNABLE_ULONG(). ??Of course, if your tunable is a boolean
: > > value or something like maxprocs, an int is fine - but so is a long.
: > 
: > Semantically valid but using TUNABLE_INT to hold pointers is a
: > developer bug, not the fault of the API, and there's nothing wrong
: > with "int" as a data type in this context.
: 
: I agree with Ivan here.  If we can't find an actual reason to
: universally prefer long I'd like to remove this comment.
: 
: As a counterpoint to the preference for long I can offer a reason to
: prefer int: the same variable is often exposed by both a tunable and a
: sysctls, and a sysctl using long can have 32-bit compat issues.  (That
: is, a 32-bit app using sysctlbyname will try to use 4 bytes for a long.)

There's absolutely no reason to not use TUNABLE_INT for simple
integers.  Back in the deep, dark, dim past, there was no
TUNABLE_*LONG.  TUNABLE_INT was introduce in r77900 by peter.  DES
added TUNABLE_LONG in r137099, as well as adding the comment.

The comment is bogus, or at least not quite specific enough.  It has
been routinely ignored since it was added.

There's absolutely nothing wrong with TUNABLE_INT.

We really should have a TUNABLE_ADDRESS for this case, although
there's at least three types of address that we need to worry about:
Physical Addresses, Virtual Addresses and Bus Addresses.  You don't
know if ULONG or LONG is the right type for an address, or if you need
a quad (for example, 32-bit MIPS can address, through PTE entries,
addresses beyond the 32-bit barrier, so you'd need a QUAD).

I'm in favor of changing the comment to:

/*
 * Please do not use for addresses or pointers
 */

Warner