2010/8/7 Ivan Voras <ivo...@freebsd.org>: > 2010/8/8 Dag-Erling Smørgrav <d...@des.no>: >> Garrett Cooper <gcoo...@freebsd.org> writes: >>> Dag-Erling Smørgrav <d...@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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"