From owner-svn-src-all@freebsd.org Fri Jul 6 02:18:52 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 D0E1D102AB6D; Fri, 6 Jul 2018 02:18:52 +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 C67308369F; Fri, 6 Jul 2018 02:18:51 +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 w662IoUG050241; Thu, 5 Jul 2018 19:18:50 -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 w662IooX050240; Thu, 5 Jul 2018 19:18:50 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201807060218.w662IooX050240@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r335916 - head/sys/conf In-Reply-To: To: John Baldwin Date: Thu, 5 Jul 2018 19:18:50 -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:18:53 -0000 [ Charset UTF-8 unsupported, converting... ] > On 7/5/18 5:13 PM, Eugene Grosbein wrote: > > 06.07.2018 6:59, John Baldwin wrote: > > > >>> 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. > > > > And what's profit of such restriction? There were several cases > > when I was forced to extract somemodule.ko from FreeBSD distribution files > > and upload it to some customized installation such as FreeNAS or NAS4Free > > or another one running custom kernel and having stripped-down module set out-of-the-box. > > For example, ichwd.ko or something like that. And I was just happy I could do that and > > that just work. Why should we break it? > > You would still do that by 'cd /sys/modules/foo; make; scp foo.ko somebox:' > > The profit of the restriction is performance. Making kernel modules > generic makes them slower by forcing them to indirect certain lightweight > operations through function calls that the kernel itself performs inline > (and "tied" modules would inline these same things). I build custom kernels with the modules compiled in if I want performant systems. I remove all the stuff I do not need or want in GENERIC for the same reason. Trying to make loaded kernel modules performant by placing near static linked kernel restrictions on them is not a direction I feel worth heading into as it breaks just too many other use cases. > The other benefit is > that providing a convenient way to recompile modules from ports would alleviate > KBI breakage for ports such as nvidia-graphics and virtualbox-ose-kmod > that can break since they use parts of the kernel for which we do not > guarantee KBI stability. Isnt that a totally seperate issue to this MODULE_TIED? > John Baldwin -- Rod Grimes rgrimes@freebsd.org