Why is TUNABLE_INT discouraged?

[Ivan Voras]

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.

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