nfslockd kernel module fails to load

[Konstantin Belousov]

On Thu, Apr 23, 2020 at 11:53:30AM +0200, Alexander Leidinger wrote:
> Quoting Konstantin Belousov <kostikbel at gmail.com> (from Thu, 23 Apr 2020
> 12:22:48 +0300):
> 
> > On Thu, Apr 23, 2020 at 09:46:02AM +0200, Alexander Leidinger wrote:
> > > 
> > > Quoting Konstantin Belousov <kostikbel at gmail.com> (from Thu, 23 Apr 2020
> > > 10:04:12 +0300):
> 
> 
> > > > MODULE_DEPEND() handles symbol namespaces.
> > > 
> > > Since when is this the case (rough figure would be enough if someone knows
> > > it without looking it up)?
> > 
> > It is definitely so from the 5.x times, but I highly suspect that this was
> 
> Thanks for the info.
> 
> > the feature of 'new' modules from the beginning.
> 
> I do not remember this behavior in 3.0. I remember cases where a module
> didn't had a dependency and manually loading the dependency before was
> enough. Memories alter over time, so I may be wrong...
> I wouldn't be surprised if this behavior was introduced more in the
> timeframe around amd64 or the reworking of module loading a while after
> amd64 (may this is what you refer to as "new modules").

No, it predates amd64 for many years.  There were 'lkm' modules, and
dfr then implemented 'kld' modules, I think around 1998, mostly confirmed
by svn log for link_elf.c.  Namespace restriction for symbol lookup for
dependencies only was in kld from the start.