Proposal: envmode/hintmode rototill

[Kyle Evans]

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