On Sun, Aug 8, 2010 at 11:14 AM, M. Warner Losh <i...@bsdimp.com> wrote: > In message: <20100808130624.gb40...@sandvine.com> > Ed Maste <ema...@freebsd.org> writes: > : On Sun, Aug 08, 2010 at 01:30:19AM +0200, Ivan Voras wrote: > : > : > 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. > : > : 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 > */
Then comes my next request: could someone please review this patch
and commit it if it's ok? This adds comments to TUNABLE_INT
(recommended by Warner) and also adds functionality for TUNABLE_UINT
as well. I have a simple module and test script attached for it.
Adding this functionality would make things more consistent with
the TUNABLE KPIs, make my experimenting with sound(4) easier, and
could help improve the sound(4) subsystem's code (I'll have to discuss
some things with ariff@, because I'm not sure whether or not some
quantities need to be signed or not).
Thanks!
-Garrett
uint_tunable.diff
Description: Binary data
_______________________________________________ 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"
