From owner-svn-src-all@freebsd.org Fri Jul 6 02:15:10 2018 Return-Path: Delivered-To: svn-src-all@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 A81B8102A58D; Fri, 6 Jul 2018 02:15:10 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1D3F8833A3; Fri, 6 Jul 2018 02:15:09 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w662F7wc050222; Thu, 5 Jul 2018 19:15:07 -0700 (PDT) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w662F6Kj050221; Thu, 5 Jul 2018 19:15:06 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201807060215.w662F6Kj050221@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r335916 - head/sys/conf In-Reply-To: <1dd03d43-6f0d-580b-fd3b-f4494da42c70@FreeBSD.org> To: John Baldwin Date: Thu, 5 Jul 2018 19:15:06 -0700 (PDT) CC: Eugene Grosbein , Konstantin Belousov , Matt Macy , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 02:15:10 -0000 > 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/) 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/ 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@freebsd.org