Why is TUNABLE_INT discouraged?

Dag-Erling Smørgrav des at des.no
Thu Aug 12 12:25:42 UTC 2010

Garrett Cooper <gcooper at FreeBSD.org> writes:
> Dag-Erling Smørgrav <des at des.no> writes:
> > It might be a good idea to introduce TUNABLE_POINTER and TUNABLE_SIZE.
> I would actually argue against doing that because it would only create
> divergence between sysctl and tunable KPIs...

Not if we also introduce corresponding SYSCTLs.  Note that my idea is to
have these as aliases for the correct primitive types.

> (BTW, when you say TUNABLE_SIZE, I assume it would be a size_t quantity?)


> Something might need to be done to the values returned by the tunables
> though, because they don't respect boundaries, and can overflow right
> now (which exacerbates the issue with values crammed into smaller
> datatypes)...

Yes.  How about this:

 - rename getenv_quad() to getenv_signed() and getenv_unsigned()
 - add min / max arguments
 - implement getenv_quad() (and all the others) in terms of


getenv_uint(const char *name, unsigned int *data)
        unsigned long long tmp;
        int rval;

        if ((rval = getenv_unsigned(name, &tmp, 0, UINT_MAX)) == 0)
                *data = (unsigned int)tmp;
        return (rval);

(note that due to the min / max arguments, the complexity of handling
both signed and unsigned values in the same function probably exceeds
the complexity of having two very similar functions)

Dag-Erling Smørgrav - des at des.no

More information about the freebsd-hackers mailing list