Date: Tue, 5 Feb 2002 19:11:05 -0800 From: Mike Smith <msmith@hub.freebsd.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Setting sysctl(8)'s in rc.conf Message-ID: <20020205191105.A25310@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
> > A better approach would be to make those items that are sysctls in > > modules also TUNABLES, and then the problem goes away. > > Will this let them be set before load? Why not go read up on tunables? /* * Infrastructure for tunable 'constants'. Value may be specified at compile * time or kernel load time. Rules relating tunables together can be placed * in a SYSINIT function at SI_SUB_TUNABLES with SI_ORDER_LAST. */ > There's a bad assumption in tunables, that they may be > tuned after boot time, which is not true for things > like sizes of zalloci() zones, which must be contiguous, There is? Since you don't actually know what TUNABLEs actually are, aren't you going out on a bit of a limb here? > and whose size prevents reallocation, and whose use > before reallocation would lead to fragmentation. This is the entire rationale behind the existence of TUNABLEs. I fail to comprehend why you're even posting this message, since you don't just have the wrong end of the stick but also appear to have missed the fact that it's a rattlesnake. For those reading this that are confused; the TUNABLE mechanism is provided to make it easy to adjust parameters that affect systems or algorithms that would not respond well to having these parameters adjusted after initialisation. Prior to TUNABLEs (which are really a very trivial thing), you would have to either recompile the kernel or patch the kernel image. TUNABLEs take a default value at compile time, and can be overridden using the loader. They occupy the same namespace as sysctl variables (this is not enforced, just a convention), and the value is often exported via sysctl so that the administrator can obtain the current value for reference purposes. - - - With regard to the original suggestion, I'm not in agreement that module arguments should be tunables either. Many module arguments should actually be hints (since they relate to instances of something supported by a module). Those that are truly generic, or in the case of a module which only creates a single instance should be passed at module load time either directly (as with the loader's 'load' command, via kldload, etc) or indirectly from a configuration file. TUNABLEs really exist to deal with the problem described above, not the issue of module arguments. Regards, Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020205191105.A25310>