Why is TUNABLE_INT discouraged?

[Garrett Cooper]

2010/10/16 Garrett Cooper <gcooper at freebsd.org>:
> 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).

Let's try with the patch attached...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tunables-enhancement.diff
Type: application/octet-stream
Size: 36773 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20101016/389a80a0/tunables-enhancement.obj