From owner-svn-src-head@freebsd.org Fri Jul 6 00:28:48 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1350B1044646; Fri, 6 Jul 2018 00:28:48 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (unknown [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8138A7E882; Fri, 6 Jul 2018 00:28:47 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w660SeHo023851 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 6 Jul 2018 02:28:41 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: jhb@FreeBSD.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w660SbS8090104 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 6 Jul 2018 07:28:37 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: svn commit: r335916 - head/sys/conf To: John Baldwin , Konstantin Belousov References: <201807032305.w63N5guY063293@repo.freebsd.org> <20180704142233.GB5562@kib.kiev.ua> <6e5bc5e4-052c-877f-1c36-c72e276ff045@FreeBSD.org> <20180705155417.GI5562@kib.kiev.ua> <2a5b1c50-0f50-bbe1-4fcd-b98f61d24571@FreeBSD.org> <5B3EA725.4010202@grosbein.net> <1dd03d43-6f0d-580b-fd3b-f4494da42c70@FreeBSD.org> <5B3EB443.50004@grosbein.net> Cc: Matt Macy , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Eugene Grosbein Message-ID: <5B3EB7AF.3040306@grosbein.net> Date: Fri, 6 Jul 2018 07:28:31 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 00:28:48 -0000 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.