Date: Thu, 23 Aug 2012 19:40:37 +0200 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Attilio Rao <attilio@freebsd.org> Cc: current@freebsd.org Subject: Re: TUNABLE_INT vs TUNABLE_INT_FETCH Message-ID: <20120823174037.GA4820@onelab2.iet.unipi.it> In-Reply-To: <CAJ-FndB1PQ%2B8rQLS%2B_Ac-i=xOckTv%2B7aV4Ma9KzJuhUe-DT8Pg@mail.gmail.com> References: <20120823145420.GB3103@onelab2.iet.unipi.it> <CAJ-FndCSfXvEmYjuEi985JPoiZYStOaqdeYsjyepHS8C55Szkw@mail.gmail.com> <20120823160543.GD3391@onelab2.iet.unipi.it> <CAJ-FndB1PQ%2B8rQLS%2B_Ac-i=xOckTv%2B7aV4Ma9KzJuhUe-DT8Pg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 23, 2012 at 04:55:05PM +0100, Attilio Rao wrote: > On Thu, Aug 23, 2012 at 5:05 PM, Luigi Rizzo <rizzo@iet.unipi.it> wrote: > > On Thu, Aug 23, 2012 at 03:52:56PM +0100, Attilio Rao wrote: > >> On 8/23/12, Luigi Rizzo <rizzo@iet.unipi.it> 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. 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. 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). Anyways, thanks for the clarificaiton, now i know what i need to use. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120823174037.GA4820>