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. 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 luigiReceived on Thu Aug 23 2012 - 15:21:29 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:30 UTC