svn commit: r335916 - head/sys/conf

[Rodney W. Grimes]

> On 7/5/18 4:17 PM, Eugene Grosbein wrote:
> > 06.07.2018 1:21, John Baldwin wrote:
> > 
> >> Yes, this is a change though I find it the logical outcome of the original change
> >> to move away from MODULES_WITH_WORLD.  And to be clear, Matt certainly only
> >> intended to use MODULE_TIED in a few places, but I think tagging all those
> >> places will be cumbersome and tedious compared to just doing it in this way.  I
> >> think this will also tie into something I proposed earlier in a commit reply and
> >> that I also brought up at BSDCan which is that I think that kernel modules in
> >> ports should install their sources and build glue to some location we choose
> >> (e.g. /usr/local/sys/modules/<foo>) and that we should support a variable folks
> >> can set in their kernel config file similar to MODULES_OVERRIDE that is a list
> >> of local modules to recompile and install into /boot/kernel along with other
> >> modules (and that these recompiled modules would be TIED).  The binary module
> >> from the package would still be present in /boot/modules, but the tied module
> >> in /boot/kernel would be preferred and used instead when it exists (our existing
> >> module_path already does this last part).  This would replace the existing
> >> PORTS_MODULES but in a way that is more graceful and works with packages, not
> >> just ports IMO.
> > 
> > I'm not sure I understand the topic quite right, but please do not drop
> > MODULES_WITH_WORLD support at it allows us to quickly rebuild the kernel
> > in case of slight changes of its config file not changing ABI and/or
> > similar source changes without HUGE modules compilation overhead.
> 
> This would not drop it, but it would mean that you can't necessarily kldload
> /boot/kernel.GENERIC/foo.ko while running some other kernel.

Please do not break that!   If any module should continue to load with a
custom kernel it should be the ones built with GENERIC, as long as the
source code/KABI is unchanged why am I not being allowed to load this module?

> > Also, we should not use /usr/local/sys/modules/<foo> as /usr/local
> > can be inaccessible for the loader. Better use /boot/modules/local or /boot/local
> > as /boot is guaranteed to be accessible.
> 
> You misunderstand.  /usr/local/sys/modules would hold module sources so that
> they can be recompiled when building a kernel without having to rebuild the
> package or reinstall the package.  Binary modules would continue to be
> installed in /boot/modules.

I like this part of it, as we discussed at BSDCan, this would in effect
fix the VirtualBox, kmod-next, and nvidia module issues we currently
face in stable/11.

> John Baldwin
-- 
Rod Grimes                                                 rgrimes at freebsd.org