Date: Mon, 17 Apr 2017 08:58:22 +0200 From: Gary Jennejohn <gljennjohn@gmail.com> To: Mark Johnston <markj@FreeBSD.org> Cc: Baptiste Daroussin <bapt@FreeBSD.org>, arch@FreeBSD.org Subject: Re: modules finding order Message-ID: <20170417085822.0af03ceb@ernst.home> In-Reply-To: <20170416221249.GA11628@raichu> References: <20170416202137.5x4vegfnm2pvkn6t@ivaldir.net> <20170416221249.GA11628@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 16 Apr 2017 15:12:49 -0700 Mark Johnston <markj@FreeBSD.org> wrote: > On Sun, Apr 16, 2017 at 10:21:37PM +0200, Baptiste Daroussin wrote: > > Hi all, > > > > I would like to change in FreeBSD 12 at least the default order the modules are > > found/look up. > > > > For now the modules are loaded from /boot/kernel first then if not found, > > checked from /boot/modules. > > > > I think we should revert that to /boot/modules first then /boot/kernel. > > > > The main reason being to simplify multiple things: > > 1/ If one needs to change a module (like backporting) I could install it from > > package and it would take precedent from the one provided by the default kernel > > I'm using > > 2/ As a hacker I could build my own version of a given module and install it in > > /boot/modules I won't overwrite the default kernel module > > This complements r299393. Since that revision went in I've confused myself > several times by building and installing a module from sys/modules, and > then forgetting to explicitly kldload from /boot/modules, so I > instead get a stale copy. > > > 3/ as a port maintainer I could provide my own version of the module that would > > take precedence over the one provided by the kernel. > > I think we would like this behaviour for a port that installs the DRM > modules. > > > > > As it is a change in the default behaviour I would only do it for 12 (beside I > > would love to do it in earlier version :D) > > > > Anyone has an opinion on the subject? > > It seems reasonable to me. > The problem I see with this is that the module under /boot/modules may have been generated against a /usr/src which is newer than what was used to generate the running kernel. In this case kldload should (I hope) fail. I regularly update /usr/src without making a new world or kernel. If kldload automatically falls back to trying /boot/kernel in this case then everything would be OK. If kldload does not or cannot retry then I would not consider this change a good idea. There's also the possibility that the module is loaded successfully, but at run time it fails due to missing functionality in the old kernel. I'm not sure that this could happen. -- Gary Jennejohn
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170417085822.0af03ceb>