Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Apr 2017 12:09:40 -0700
From:      Mark Johnston <markj@FreeBSD.org>
To:        Gary Jennejohn <gljennjohn@gmail.com>
Cc:        Baptiste Daroussin <bapt@FreeBSD.org>, arch@FreeBSD.org
Subject:   Re: modules finding order
Message-ID:  <20170417190940.GC18960@wkstn-mjohnston.west.isilon.com>
In-Reply-To: <20170417085822.0af03ceb@ernst.home>
References:  <20170416202137.5x4vegfnm2pvkn6t@ivaldir.net> <20170416221249.GA11628@raichu> <20170417085822.0af03ceb@ernst.home>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 17, 2017 at 08:58:22AM +0200, Gary Jennejohn wrote:
> 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 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.

It may or may not; the load will fail if the running kernel's
__FreeBSD_version does not match the value that the module was compiled
with. If the __FreeBSD_version values match, then the module is in
theory compatible with the running kernel and should just work.

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

I don't think there's any mechanism to fall back. A
"kldload foo" from the command line will cause the kernel to try and
load the first "foo.ko" found in the paths given by the kern.module_path
sysctl value. If that fails, the kldload fails. I'm not sure how it
works for modules loaded by loader(8).

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170417190940.GC18960>