From owner-freebsd-current@FreeBSD.ORG Thu Aug 23 17:52:23 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 154A9106564A; Thu, 23 Aug 2012 17:52:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id DCB4D8FC08; Thu, 23 Aug 2012 17:52:22 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4E6EAB963; Thu, 23 Aug 2012 13:52:22 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 23 Aug 2012 13:49:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120823145420.GB3103@onelab2.iet.unipi.it> <20120823174037.GA4820@onelab2.iet.unipi.it> In-Reply-To: <20120823174037.GA4820@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208231349.06372.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 23 Aug 2012 13:52:22 -0400 (EDT) Cc: Attilio Rao , Luigi Rizzo , current@freebsd.org Subject: Re: TUNABLE_INT vs TUNABLE_INT_FETCH X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 17:52:23 -0000 On Thursday, August 23, 2012 1:40:37 pm Luigi Rizzo wrote: > On Thu, Aug 23, 2012 at 04:55:05PM +0100, Attilio Rao wrote: > > On Thu, Aug 23, 2012 at 5:05 PM, Luigi Rizzo wrote: > > > On Thu, Aug 23, 2012 at 03:52:56PM +0100, Attilio Rao wrote: > > >> On 8/23/12, Luigi Rizzo wrote: > > >> > Hi, > > >> > I am a bit unclear on what are the pros and cons of using > > >> > TUNABLE_INT vs TUNABLE_INT_FETCH within a device driver. > > >> > > >> TUNABLE_INT is basically the "statically initializer" version of > > >> TUNABLE_INT_FETCH. > > >> In short terms, you will use TUNABLE_INT_FETCH() in normal functions, > > >> while TUNABLE_INT() in data declaration. > > > > > > The thing is, do we need the data declaration at all ? > > > > What do you mean with "data declaration"? > > i am using your words :) > > > We need to mimic a "static initialization" usage, so what we do is to > > use the first SYSINIT() family available (SI_SUB_TUNABLES). You also > > need the env to look for and the static variable to initialize, so for > > SYSINIT's sake you need to pack them up in a single argument. > > To explain: as i understand it, kenv variables are created and stored > (presumably as strings) even if not explicitly declared as > TUNABLE_*(). The role of the SYSINIT() block is presumably to > copy the values of interesting entries into C variables > (i suppose at boot time, and perhaps even when kenv runs). > This should be the 'static initialization' you mention. Only at boot time, they are unaffected by 'kenv' running. This is why most tunables that can be changed at runtime have a sysctl of the same name. > I think there is only a limited number of cases where this makes sense, > in most circumstances the variables passed through the environment > should be read explictly via TUNABLE_INT_FETCH() to make sure that > they do not change in unexpected moments. kenv can't change during boot. > This is why in the documentation I'd probably suggest to use > the TUNABLE_*_FETCH() variant unless you are really really > sure that the variable can change at any time as a result of > a kenv call (or make it clear that it *will not* reflect > the kenv result, i am not sure how it works). They have never, ever reflected kenv calls. They are always used for boottime evaluation, and if the code wishes to allow post-boot changes it exports a sysctl of the same name for that purpose. In many cases the code will export a read-only sysctl of the same name even if it can't be changed (this is especially useful for values that have an auto-calculated value if none is provided). -- John Baldwin