From owner-freebsd-arch Wed Jun 20 10:19:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 5EB9F37B401; Wed, 20 Jun 2001 10:19:28 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.244.104.7.Dial1.SanJose1.Level3.net [209.244.104.7]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id KAA13907; Wed, 20 Jun 2001 10:19:18 -0700 (PDT) Message-ID: <3B30DB35.493B0D92@mindspring.com> Date: Wed, 20 Jun 2001 10:19:49 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: John Baldwin , arch@FreeBSD.ORG, Peter Pentchev , Nate Williams Subject: Re: new kldpath(8): display/modify the module search path References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 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[]. My impression is that the intent is to (ab)use this mechanism to hint to the kernel where to get modules so that it can demand-load them itself. I'm not opposed to the idea of the kernel doing this (I'm all for it, and have been since 1994, when I was shouted doun from puting a KLD-like linker into the newly released LKM infrastructure), but I'm very opposed to the kernel/loader being able to do this without giving me an opportunity to override to recover from a foot-shooting/shoot-footing. John Baldwin says that UNIX has traditionally permitted foot-shooting. Yes. But even in the worst cases, it has never offered to hold your foot for you. I think this code is premature. I think that the module/kernel version mismatch needs to be addressed (minimally, by gross version number and date) and the seperate, discardable "probe" segments first, so that: 1) The kernel can know it is demanding a bad thing, and refuse to do it, and 2) There is a way for the kernel to know that what it is demanding will end up having a positive overall effect. Only after that, does it make sense to provide a path for it to use for demand-loading. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message