Why is TUNABLE_INT discouraged?

[Dag-Erling Smørgrav]

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?)

Yes.

> 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_number()

e.g. 

int
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)

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