2010/10/16 Garrett Cooper <gcoo...@freebsd.org>: > 2010/8/12 Dag-Erling Smørgrav <d...@des.no>: >> Garrett Cooper <gcoo...@freebsd.org> writes: >>> Dag-Erling Smørgrav <d...@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...
tunables-enhancement.diff
Description: Binary data
_______________________________________________ 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"