From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 8 18:17:09 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81B09106564A; Sun, 8 Aug 2010 18:17:09 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 242A78FC0A; Sun, 8 Aug 2010 18:17:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o78IEHi4044758; Sun, 8 Aug 2010 12:14:17 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 08 Aug 2010 12:14:50 -0600 (MDT) Message-Id: <20100808.121450.752311254854610266.imp@bsdimp.com> To: emaste@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20100808130624.GB40928@sandvine.com> References: <864of680wv.fsf@ds4.des.no> <20100808130624.GB40928@sandvine.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: des@des.no, freebsd-hackers@FreeBSD.org, gcooper@FreeBSD.org, ivoras@FreeBSD.org, Garrett@FreeBSD.org Subject: Re: Why is TUNABLE_INT discouraged? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 18:17:09 -0000 In message: <20100808130624.GB40928@sandvine.com> Ed Maste writes: : On Sun, Aug 08, 2010 at 01:30:19AM +0200, Ivan Voras wrote: : : > 2010/8/8 Dag-Erling Sm??rgrav : : > > Garrett Cooper writes: : > >> Dag-Erling Sm??rgrav 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 */ Warner