Date: Wed, 06 Nov 2002 04:52:05 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Maxime Henrion <mux@freebsd.org> Cc: "M. Warner Losh" <imp@bsdimp.com>, chuck_tuffli@agilent.com, freebsd-hackers@FreeBSD.ORG Subject: Re: load time module parameters? Message-ID: <3DC91075.6BB1B4C5@mindspring.com> References: <20021105222958.GH17013@cre85086tuf.rose.agilent.com> <20021105.222147.10576668.imp@bsdimp.com> <20021106104421.GK26605@elvis.mu.org> <3DC9035A.3DFCF3BB@mindspring.com> <20021106122925.GM26605@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Maxime Henrion wrote: > > The kernel environment is most useful for diagnostic porposes, and > > for use in the way descrived in this thread -- to provide a means > > of passing parameters that should not be parameters to modules that > > should not need parameters in the first place. Many times, hacking > > the values post-boot will have little or no effect. It's too bad > > the things that will have no effect were exported as writeable, > > instead of resulting in an error. > > I agree this is not perfect, but I don't think we should return an error > though. It would be bad to start duplicating the sysctl functionality > into the kernel environment. What could be nice would be to unsetenv() > the environment variables after them being read and used, so that people > typing kenv won't see these variables in the output and so won't be > tempted to set them. They are too useful for reporting purposes. Without their values, you can't tell the boot environment, and therefore the code that's actually running in the kernel, without a lot more effort, and that would mean duplicated code. There's also the problem of a value that used more than once; the counter argument is to clear them after everything's up -- but that doesn't address things which may or may not be modules. I guess I'm saying that the read-onlyness is cautionary: you can not expect some things to change and be valid. The "maxfiles" example is actually a sysctl, unless you override specifically in the boot loader, in which case it's both a sysctl and in the environment. Even so, after a sysctl change, the environment value (if present) would not be changed. The name space is effective "snapshotted" into the sysctl space when the TUNABLE's are processed from the environment, and interned to kernel data values, instead. With that in mind, it's probably a much better idea to use sysctl's instead of parameters, but the kenv has the advantage of being able to specify initialization parameters. Really, it's a very bad idea to write kernel code that needs command line arguments in the first place, at all. I guess it's something that has to be lived with, as people port Linux code to FreeBSD... but not something to be encouraged. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DC91075.6BB1B4C5>