Why is TUNABLE_INT discouraged?

[Garrett Cooper]

2010/8/7 Ivan Voras <ivoras at freebsd.org>:
> 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.

Why would someone express a tunable in a memory address (not being
sarcastic... I just don't see why it makes sense right now, but if
there's a valid reason I'm more than happy to be educated :)..)?

> 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.
>
> Unless there is a real hidden danger in using TUNABLE_INT (and/or
> adding TUNABLE_UINT etc.) in the expected way, I'd vote for either
> removing the cautioning comment or rewriting it to say something like
> "developers are hereby warned that ints cannot hold pointers on all
> architectures", if it is indeed such a little known fact among kernel
> developers :P

*grins cheekily in agreement* :).

Thanks,
-Garrett