svn commit: r332091 - stable/11/sys/vm

[Slawa Olhovchenkov]

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/<foo> and a
> 'LOCAL_MODULES' kernel option that is a list of '<foo> <bar>' 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.