svn commit: r335916 - head/sys/conf

[Eugene Grosbein]

06.07.2018 7:20, John Baldwin wrote:

>>> 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:'

Yes, provided I have a buildbox handy.

> 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).  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.

Thanks, now I got it.