From owner-svn-src-head@freebsd.org Thu Jul 5 18:39:43 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3CD5610220C4; Thu, 5 Jul 2018 18:39:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C23148FA2B; Thu, 5 Jul 2018 18:39:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w65IdZ5r017838 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Jul 2018 21:39:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w65IdZ5r017838 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w65IdYo9017837; Thu, 5 Jul 2018 21:39:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 5 Jul 2018 21:39:34 +0300 From: Konstantin Belousov To: John Baldwin Cc: Matt Macy , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r335916 - head/sys/conf Message-ID: <20180705183934.GL5562@kib.kiev.ua> References: <201807032305.w63N5guY063293@repo.freebsd.org> <20180704142233.GB5562@kib.kiev.ua> <6e5bc5e4-052c-877f-1c36-c72e276ff045@FreeBSD.org> <20180705155417.GI5562@kib.kiev.ua> <2a5b1c50-0f50-bbe1-4fcd-b98f61d24571@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a5b1c50-0f50-bbe1-4fcd-b98f61d24571@FreeBSD.org> User-Agent: Mutt/1.10.0 (2018-05-17) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 18:39:43 -0000 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/. > > > >> 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/) 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.