Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Jun 2001 09:37:30 +0300
From:      Peter Pentchev <roam@orbitel.bg>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Nate Williams <nate@yogotech.com>, John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG, audit@FreeBSD.ORG
Subject:   Re: new kldpath(8): display/modify the module search path
Message-ID:  <20010620093730.C558@ringworld.oblivion.bg>
In-Reply-To: <3B3041D7.28CB375E@mindspring.com>; from tlambert2@mindspring.com on Tue, Jun 19, 2001 at 11:25:27PM -0700
References:  <XFMail.010615122501.jhb@FreeBSD.org> <3B2F958E.BC556A1E@mindspring.com> <15151.41572.721434.703837@nomad.yogotech.com> <3B3041D7.28CB375E@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 19, 2001 at 11:25:27PM -0700, Terry Lambert wrote:
> Nate Williams wrote:
> > > Having to reboot to make things work really, really sucks --
> > > and that is often necessary if you build code from the net,
> > > which FreeBSD has mistakenly included as part os the base
> > > system monolith.  OpenSSL, OpenSSH, and the resolver library
> > > are three examples that leap lithely to mind.
> > 
> > Terry, it's simple to not have to reboot.  Many ports already
> > do this, but a 'ldconfig -R' tells it to re-scan the known
> > directories to pickup new entries, which can be done at any
> > time (as root of course).
> 
> It was pointed out that the code just sets a path (or adds
> to one, which makes the most sense in the case of multiple
> rc.d's).
> 
> I still have a small problem with the path setting automating
> load of things installed in /usr/local (e.g. the vmware
> modules), since there isn't a "rebuild requirement" for the
> modules which are not themselves built as part of the kernel
> build.

If you are not prepared to rebuild them automatically, don't autoload
them.  Just setting the path does NOT cause module autoloading,
you have to explicitly invoke kldload() to load a module.
If the module was loaded automatically before, it will be loaded
automatically now, too, regardless of the path setting.

> I also have a slight problem with the module path being
> capable of being set to include some directory before
> /modules.

If you don't want to do this, don't do it.  It's as simple as that.

> What is the interaction with /etc/modules.old, when you are
> booting a /kernel.old?
>
> It seems to me that it would be very easy to boot a /kernel.old,
> and end up with mismatched modules from an rc file setting the
> path to /modules instead of /modules.old...

In -current, booting a /boot/kernel.old/ automatically sets
the module search path to /boot/kernel.old/.  There are no
rc files involved, the default search path is set by the loader
and the kernel themselves (look at sys/kern/kern_linker.c).

> This seems like something that should maybe be a sysctl,
> instead, and have a default behaviour of "append to path"
> in the rc file implementation, to ensure that the booted
> kernel and modules directory matched, no matter what
> kernel you booted.

It is a sysctl already, and the kernel does ensure the booted
kernel and modules directory match.  If you later call kldconfig(8)
without a -m option, you shoot yourself in the foot.
If you call ldconfig(8) without an -m option, you shoot yourself
in the foot.

> I might even go so far as to say that if a kernel other
> than /kernel was being booted, that it ought to become
> read-only, to prevent a mismatched module from being
> loaded unintentionally...

Hmm.. this, at last, is a really interesting idea that does
deserve some thought :)  However, it is a part of the next round
of changes - the kernel linker itself validating the module
search paths set by kldconfig(8), or (currently and since forever)
by the sysctl.

G'luck,
Peter

-- 
This would easier understand fewer had omitted.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




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