From owner-freebsd-arch Tue Jun 19 23:39:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id AF51D37B403 for ; Tue, 19 Jun 2001 23:39:02 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 4878 invoked by uid 1000); 20 Jun 2001 06:37:30 -0000 Date: Wed, 20 Jun 2001 09:37:30 +0300 From: Peter Pentchev To: Terry Lambert Cc: Nate Williams , John Baldwin , arch@FreeBSD.ORG, audit@FreeBSD.ORG Subject: Re: new kldpath(8): display/modify the module search path Message-ID: <20010620093730.C558@ringworld.oblivion.bg> Mail-Followup-To: Terry Lambert , Nate Williams , John Baldwin , arch@FreeBSD.ORG, audit@FreeBSD.ORG References: <3B2F958E.BC556A1E@mindspring.com> <15151.41572.721434.703837@nomad.yogotech.com> <3B3041D7.28CB375E@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B3041D7.28CB375E@mindspring.com>; from tlambert2@mindspring.com on Tue, Jun 19, 2001 at 11:25:27PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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