Date: Wed, 20 Jun 2018 23:38:57 -0500 From: Kyle Evans <kevans@freebsd.org> To: freebsd-arch@freebsd.org Cc: freebsd-embedded@freebsd.org Subject: Proposal: envmode/hintmode rototill Message-ID: <CACNAnaG-mLhfohFGiP5LPpDLc5nJ8GqO7nvYzO=8KmaK9162rQ@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hello! The current situation with envmode/hintmode (see: config(5), `env` and `hints` respectively) is less than ideal, and conflicts with some future needs that I have. There will be a decent summary after the next couple paragraphs of background. The problem is that config(5) supplied env/hints are mutually exclusive with loader.conf(5)-driven kenv. The hints situation is slightly better as it can be altered with a sysctl that switches to the dynamic environment and thus pulls in any static hints supplied through config(5) along with whatever hints might have appeared in the chosen static kenv and those mixed in after the switch to dynamic environment. The way I need it to work is that config(5) supplied env is effectively a seed for the static environment. This would then get augmented with whatever MD environment (generally from loader(8)) has been specified. A poor example goal is to be able to have a kernconf with `options VERBOSE_SYSINIT` and debug.verbose_sysinit=0 set to quiet it by default, then have the ability to add in debug.verbose_sysinit=1 through loader(8) to make the VERBOSE_SYSINIT behavior verbose again. This is a bad example because this could be accomplished with `options VERBOSE_SYSINIT=0`, but I think it gets the point across- the kernconf environment is a set of reasonable defaults that may be overwritten by the loader. I had initially thought that maybe there were security considerations to be had here, but loader(8) static env can be switched to by including static_env.disabled=1 in said env- so it wasn't always ignored in the current world order. SUMMARY: I would like to: 1.) Eradicate envmode/hintmode 2.) Augment kernconf env with loader(8) supplied env 3.) Prior to the dynamic environment being setup, hint searches will be conducted across the two dfferent kinds of static environments (if applicable) as well as any static hints that were supplied, in order: loader(8) env, config(5) env, config(5) hints 4.) After the dynamic environment is provisioned (from loader(8) and config(5) environments), add in config(5) hints 5.) Once all of these environments have been merged into the dynamic environment, all hint searches should then just search the dynamic environment. This seems to be the common case for searches at the moment; the dynamic environment is completely merged by the end of SI_SUB_KMEM In the New World Order, there is no such thing as ignoring any of these environments. Each one is either provided or not, and the kernel will use them if they're provided. I have a pretty-close-to-finished patch implementing all of the above. Thoughts? Is there a reason this is a really bad idea? Thanks, Kyle Evans
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaG-mLhfohFGiP5LPpDLc5nJ8GqO7nvYzO=8KmaK9162rQ>