[ 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 rgri...@freebsd.org _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
