From owner-freebsd-arch Wed Jun 20 3: 3: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 2A58537B401; Wed, 20 Jun 2001 03:02:57 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id UAA17927; Wed, 20 Jun 2001 20:02:53 +1000 Date: Wed, 20 Jun 2001 20:01:04 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: 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 Tue, 19 Jun 2001, John Baldwin wrote: > On 20-Jun-01 Terry Lambert wrote: > > What is the interaction with /etc/modules.old, when you are > > booting a /kernel.old? > > In -current (which is where kldconfig(8) is going, btw) all modules live with > their correspnding kernel in the same directory under /boot. Thus modules and > kernel are in sync for kernel.old, kernel, and > kernel.fix_it_after_joe_random_committer_broke_it. 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message