Date: Tue, 05 Feb 2002 22:32:45 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Alfred Perlstein <bright@mu.org> Cc: "M. Warner Losh" <imp@village.org>, cjclark@alum.mit.edu, cristjc@earthlink.net, mike@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Setting sysctl(8)'s in rc.conf Message-ID: <3C60CE0D.34F10210@mindspring.com> References: <20020205121345.B368@gohan.cjclark.org> <20020205.135658.102576700.imp@village.org> <3C609B28.4B040672@mindspring.com> <20020205.210025.88474927.imp@village.org> <20020205202809.C59017@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > No, I think he meant compile time instead of boot time, someone may > set maxuser = 0 via loader and cause bad behaviour, he seems to > want a loader tunable for this. Yes. Basically: o I want to be able to change everything I can at compile time. o I want to be able to change everything I can at boot time, except those things that can *only* be changed at compile time. o I want to be able to change everything I can at run time, except those things that can *only* be changed at boot time or compile time. In other words, the set of things increases towards boot time, and the set of modifiable things decreases towards run time. The change that Matt suggested for the loader tunable is OK to do this, but... it really points up the difference between tunable space (loader environment), sysctl space, and compile time options. Obviously, the ideal situation is that everything is tunable at runtime, without restriction. The next best thing is that the set of stuff which can be tunable is a group of nested sets, with the set being delimited by read/write vs. read-only. Right now there are about 6 different sets; this _could_ be collapsed to 3. Is there any good reason that all tunables should not be in sysctl space, or that all sysctl values should not be capable of having inital values set in the loader, and that the set of compile time things be limited to the compiler technology limits (e.g. kernel base address, KVA space size, etc.)? -- Terry 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?3C60CE0D.34F10210>
