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.
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 _______________________________________________ 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"
