From owner-freebsd-arch Wed Jun 20 21:10: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from takhus.dyn.mind.net (AFN-Dyn-63151110123.pc.ashlandfiber.net [63.151.110.123]) by hub.freebsd.org (Postfix) with ESMTP id 520D537B401; Wed, 20 Jun 2001 21:10:04 -0700 (PDT) (envelope-from takhus@takhus.mind.net) Received: from localhost (fleisher@localhost) by takhus.dyn.mind.net (8.11.4/8.11.4) with ESMTP id f5L49qb18856; Wed, 20 Jun 2001 21:09:53 -0700 (PDT) (envelope-from takhus@takhus.mind.net) X-Authentication-Warning: takhus.dyn.mind.net: fleisher owned process doing -bs Date: Wed, 20 Jun 2001 21:09:52 -0700 (PDT) From: Tony Fleisher X-Sender: fleisher@takhus.dyn.mind.net To: Bruce Evans Cc: John Baldwin , Terry Lambert , arch@FreeBSD.ORG, Peter Pentchev , Nate Williams Subject: Re: new kldpath(8): display/modify the module search path In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Wed, 20 Jun 2001, Bruce Evans wrote: > > This means that the existence of a module search path is just a bug. > The kernel shouldn't use a search path or add a path prefix for > kldload(2) any more than it should for execve(2), but adding a path > prefix is necessary for modules loaded directly by the kernel. I used > to think that a search path (with one element) was necessary for > locating the modules, but now the modules are together with the kernel, > the one-element search path can be derived from kernelname[]. > > Bruce > The primary value (at least as I see it) in having the search path is to be able to keep 3rd party kernel modules outside of /boot/kernel (or where ever your kernel happens to be) and still be able to have them loaded. I believe that the existence of the module search path (at least its current form) was explained in this commit message (abreviated to include only the most relevant sections to conserve space here)... dcs 2000/09/08 21:52:35 PDT Modified files: sys/boot/forth loader.4th loader.conf support.4th Log: First tackle at trying to handle the New Deal on kernels. [...] After a kernel was loaded, the variable module_path may get changed. Such change will happen if the kernel was found with a directory prefix. In that case, the module path will be set to ${directory};${module_path}. Next, the modules are loaded as usual. This is intended so kernel="xyzzy" in /boot/loader.conf will load /boot/xyzzy/kernel.ko, load system modules from /boot/xyzzy/, and load third party modules from /boot/modules or /modules. If that doesn't work, it's a bug. [...] The semantics introduced here are experimental. Even if the code works, we might decide this is not the prefered behavior. If you feel so, send your feedback. (Yeah, this belongs in a HEADS UP or something, but I've been working for the past 16 hours on this stuff, so gimme a break.) Revision Changes Path 1.12 +15 -113 src/sys/boot/forth/loader.4th 1.32 +3 -3 src/sys/boot/forth/loader.conf 1.7 +265 -5 src/sys/boot/forth/support.4th To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message