Date: Thu, 23 Aug 2012 18:05:43 +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: <20120823160543.GD3391@onelab2.iet.unipi.it> In-Reply-To: <CAJ-FndCSfXvEmYjuEi985JPoiZYStOaqdeYsjyepHS8C55Szkw@mail.gmail.com> References: <20120823145420.GB3103@onelab2.iet.unipi.it> <CAJ-FndCSfXvEmYjuEi985JPoiZYStOaqdeYsjyepHS8C55Szkw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ?
Using getenv_*() to read the value of a tunable (which is
what TUNABLE_INT_FETCH() translates into) has the additional
making sure that the variable does not change under your feet
e.g. as a result of a kenv.
FWIW, the reason i do not particularly like the non-fetch version
is the way they are defined:
#define TUNABLE_INT(path, var) \
static struct tunable_int __CONCAT(__tunable_int_, __LINE__) = { \
(path), \
(var), \
}; \
SYSINIT(__CONCAT(__Tunable_init_, __LINE__), \
SI_SUB_TUNABLES, SI_ORDER_MIDDLE, tunable_int_init, \
&__CONCAT(__tunable_int_, __LINE__))
note how the identifier uses __LINE__ to make it unique,
which means that you cannot have more than one TUNABLE_INT()
within the body of another macro (this just hit me yesterday).
cheers
luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120823160543.GD3391>