From owner-svn-src-head@freebsd.org Thu Jul 5 23:59:11 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 EC45A104198C; Thu, 5 Jul 2018 23:59:10 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A04757D22F; Thu, 5 Jul 2018 23:59:10 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id EDD7710A87D; Thu, 5 Jul 2018 19:59:07 -0400 (EDT) Subject: Re: svn commit: r335916 - head/sys/conf To: Eugene Grosbein , Konstantin Belousov 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> <5B3EA725.4010202@grosbein.net> Cc: Matt Macy , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: John Baldwin Message-ID: <1dd03d43-6f0d-580b-fd3b-f4494da42c70@FreeBSD.org> Date: Thu, 5 Jul 2018 16:59:07 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <5B3EA725.4010202@grosbein.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 05 Jul 2018 19:59:08 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean 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 23:59:11 -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. > 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. -- John Baldwin