Date: Thu, 5 Jul 2018 12:40:01 -0700 From: John Baldwin <jhb@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Matt Macy <mmacy@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r335916 - head/sys/conf Message-ID: <9c8d5aeb-c85b-8891-a67d-00208ad036cb@FreeBSD.org> In-Reply-To: <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> <20180705183934.GL5562@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/5/18 11:39 AM, Konstantin Belousov wrote: > 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. I am not quite saying to abolish KBI as I don't think we need to ban the ability to build standalone modules. I just think that modules built with a kernel should be tied to that kernel. In particular as there is a push to move from GENERIC towards MINIMAL, where more things like drivers are pulled from modules instead of the base kernel file, there is a need for modules built with the kernel to be less pessimized. It is actually that factor more than others that makes me want to tie modules built with a kernel to the kernel. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9c8d5aeb-c85b-8891-a67d-00208ad036cb>