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. _______________________________________________ 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"