Date: Thu, 5 Jul 2018 19:18:50 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: John Baldwin <jhb@freebsd.org> Cc: Eugene Grosbein <eugen@grosbein.net>, Konstantin Belousov <kostikbel@gmail.com>, 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: <201807060218.w662IooX050240@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <b89ad5e7-9b65-54d8-652c-5ed3315cd108@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201807060218.w662IooX050240>