svn commit: r335916 - head/sys/conf

[Rodney W. Grimes]

[ 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 at freebsd.org