svn commit: r335916 - head/sys/conf

[Konstantin Belousov]

On Thu, Jul 05, 2018 at 11:21:28AM -0700, John Baldwin wrote:
> On 7/5/18 8:54 AM, Konstantin Belousov wrote:
> > On Thu, Jul 05, 2018 at 07:56:22AM -0700, John Baldwin wrote:
> >> On 7/4/18 7:22 AM, Konstantin Belousov wrote:
> >>> On Tue, Jul 03, 2018 at 11:05:42PM +0000, Matt Macy wrote:
> >>>> Author: mmacy
> >>>> Date: Tue Jul  3 23:05:42 2018
> >>>> New Revision: 335916
> >>>> URL: https://svnweb.freebsd.org/changeset/base/335916
> >>>>
> >>>> Log:
> >>>>   Enable MODULE_TIED by default for modules compiled with the kernel
> >>> But why ?
> >>
> >> I think we should enable KLD_TIED to inline critical_* etc. for modules
> >> built as part of a kernel that are installed alongside the kernel in /boot/<kerneldir>.
> > 
> >> I don't think we need to support modules built with kernel A loaded into kernel B.
> >>
> > This is the crusial point.  I do not object, but this this is a radical
> > change from the previous mode of modules build.
> > 
> > I do not want to put words in other person mouth, but I beliee that the
> > original intent of KLD_TIED/MODULE_TIED was much more limited.  Only some
> > specific modules were to be tied.
> 
> 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 probably need to say more explicit why this change made me surprised,
and the surprise is fueled even more by your proposal.  It basically
means that we do not need stable KBI, and detecting KBI breakage in such
setup is practically impossible.  Most consumers would be recompiled,
except the modules used in very specific scenario:  inter-release updates
with the modules used from the portmgr-provided packages while packages
are still built against the older release.

Again, I do not object against the proposed new world order, I do not
believe that KBI stability gives positive value comparing with the burden
and restrictions it puts on the liveness of the stable branches.

But I do believe that the migration to such new attitude to the kernel
interfaces would benefit from the discussion.