Why is TUNABLE_INT discouraged?

[Garrett Cooper]

2010/8/9 Dag-Erling Smørgrav <des at des.no>:
> Garrett Cooper <gcooper at FreeBSD.org> writes:
>> Why would someone express a tunable in a memory address (not being
>> sarcastic... I just don't see why it makes sense right now, but if
>> there's a valid reason I'm more than happy to be educated :)..)?
>
> A few examples:
>
> hw.acpi.host_mem_start
> hw.pci.host_mem_start
> hw.physmemstart
>
> The following are not addresses, but can be > 32 bits on 64-bit machines
> and even on some 32-bit machines using PAE / PTE:
>
> hw.physmem
> vm.kmem_size
> vm.kmem_size_max
> vm.kmem_size_min

Ok -- good to know.

> 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... but that's just me. The
patch I provided before would converge sysctl and tunables a bit more
(and I'd more than happily submit patches for the other missing cases
on the sysctl side to get parity with the tunables). If it makes sense
to add the sysctls _and_ the tunables for POINTER and SIZE though,
I'll provide a patch for both cases in one shot.

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

Thanks!
-Garrett