Re: TUNABLE_INT vs TUNABLE_INT_FETCH

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 <rizzo_at_iet.unipi.it> wrote:
> > > On Thu, Aug 23, 2012 at 03:52:56PM +0100, Attilio Rao wrote:
> > >> On 8/23/12, Luigi Rizzo <rizzo_at_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.

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