Why is TUNABLE_INT discouraged?

[Garrett Cooper]

2010/8/12 Dag-Erling Smørgrav <des at des.no>:
> 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)

Here's a draft of this work des@ challenged me to a while back. It
works well as demonstrated with my tests. The only catch with
detecting bounds is that if it's the minimum in the case of signed or
maximum representable value in the case of unsigned, then strtoq, etc
will clamp the value to the maximum representable value.

Other than that it works well, and now tunables represented by
unsigned values should work better.

Please let me know what you all think.

Thanks!
-Garrett

PS I added uquad_t for consistency in the APIs, even though quad_t was
deprecated, but I didn't bump __FreeBSD_version__ -- wasn't sure if I
should have done that).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-tunables-draft1.log
Type: application/octet-stream
Size: 6573 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20101016/a9fc67b1/test-tunables-draft1.obj