2010/8/9 Dag-Erling Smørgrav <d...@des.no>: > Garrett Cooper <gcoo...@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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
