Proposal: envmode/hintmode rototill

Kyle Evans kevans at freebsd.org
Thu Jun 21 15:40:48 UTC 2018


On Wed, Jun 20, 2018 at 11:38 PM, Kyle Evans <kevans at freebsd.org> wrote:
> 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

I've created a phabricator review for my proposed patch here:
https://reviews.freebsd.org/D15953 -- this contains the actual
rototill as well as associated config(5)/config(8) changes.

Thanks,

Kyle Evans


More information about the freebsd-embedded mailing list