From owner-svn-src-stable@freebsd.org Thu Apr 12 16:44:20 2018 Return-Path: Delivered-To: svn-src-stable@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 433DEFA3132; Thu, 12 Apr 2018 16:44:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB99C71289; Thu, 12 Apr 2018 16:44:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 394A810AFCD; Thu, 12 Apr 2018 12:44:19 -0400 (EDT) From: John Baldwin To: Slawa Olhovchenkov Cc: Konstantin Belousov , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-11@freebsd.org Subject: Re: svn commit: r332091 - stable/11/sys/vm Date: Thu, 12 Apr 2018 09:24:15 -0700 Message-ID: <2836835.6EQUElDheF@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <20180411214935.GQ4305@zxy.spb.ru> References: <201804060925.w369P8c2019558@repo.freebsd.org> <2552898.N5SmTfmv87@ralph.baldwin.cx> <20180411214935.GQ4305@zxy.spb.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 12 Apr 2018 12:44:19 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2018 16:44:20 -0000 On Thursday, April 12, 2018 12:49:35 AM Slawa Olhovchenkov wrote: > On Wed, Apr 11, 2018 at 02:27:48PM -0700, John Baldwin wrote: > > > On Wednesday, April 11, 2018 10:49:20 PM Konstantin Belousov wrote: > > > On Wed, Apr 11, 2018 at 08:52:08AM -0700, John Baldwin wrote: > > > > On Monday, April 09, 2018 07:29:09 PM Slawa Olhovchenkov wrote: > > > > > On Fri, Apr 06, 2018 at 09:25:08AM +0000, Konstantin Belousov wrote: > > > > > > > > > > > Author: kib > > > > > > Date: Fri Apr 6 09:25:08 2018 > > > > > > New Revision: 332091 > > > > > > URL: https://svnweb.freebsd.org/changeset/base/332091 > > > > > > > > > > > > Log: > > > > > > MFC r331760: > > > > > > Make vm_map_max/min/pmap KBI stable. > > > > > > > > > > > > Modified: > > > > > > stable/11/sys/vm/vm_map.c > > > > > > stable/11/sys/vm/vm_map.h > > > > > > Directory Properties: > > > > > > stable/11/ (props changed) > > > > > > > > > > -STABLE still crashed after load vboxnet build on 11.1-RELEASE > > > > > nvidia (build on 11.1-RELEASE) also don't work > > > > > > > > Yes, this only helps with the future KBI, it doesn't restore the > > > > existing one. However, r320889 which was committed earlier should > > > > have restored the KBI? > > > > > > I am not sure. It might have, but there might be more breakage > > > accumulated. My current opinion is that both vbox and nvidia (as well as > > > in-tree and out of tree drm modules) must be marked as tied. The modules > > > definitely depends on much more kernel interfaces than a typical HBA or > > > network controller driver, for which the stability claim is actually > > > intended to apply. > > > > I do think virtualbox is probably too hard to make work, but I didn't think > > the nvidia driver was that bad. > > > > I think that for kmods in ports we should consider moving to a different model > > than we currently do where the port installs the source for the kernel > > module to a standard location and we could have a way to rebuild all of the > > modules as needed. This would permit us to provide PORTS_MODULES-type > > functionality via either ports or packages (and it is a bit more flexible as > > you wouldn't to deinstall/reinstall the package each time you just wanted to > > rebuild the kernel module). > > > > I would suggest something like /usr/local/src/modules/ and a > > 'LOCAL_MODULES' kernel option that is a list of ' ' to replace > > PORTS_MODULES. A package could still ship an initial module by default, but > > recompiling the module would either overwrite it, or if the module is built as > > part of the kernel (via LOCAL_MODULES) the new one would be installed with the > > kernel itself into /boot/kernel leaving the one from the package in > > /boot/modules. For tied modules we could simply build it with a strict > > MODULE_DEPEND line on the kernel so that the pre-built module won't load on > > newer kernels and then encourage the user to use LOCAL_MODULES in pkg-message. > > Using LOCAL_MODULES would be better than PORTS_MODULES as it would DTRT if you > > move kernel to kernel.old during an upgrade, etc. > > Hmm, what about packages? I am use nvidia driver as package. Yes, in this model, the package would include the necessary sources to rebuild the kernel module as part of the package, installed to /usr/local/src/modules/nvidia-driver or some such. The package could still install a pre-built module to /boot/modules/nvidia-driver.ko, but if you had 'options LOCAL_MODULES="nivida-driver" in your kernel config, then each time you built a kernel it would build an nvidia-driver.ko from /usr/local/src/modules/nvidia-driver that would be installed to /boot/kernel and would thus take precedence over the version in /boot/modules. For kernel modules that really need to be tied to the current kernel we would recommend using LOCAL_MODULES when using custom kernels in the pkg-message. -- John Baldwin