Date: Wed, 20 Jun 2001 10:19:49 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Bruce Evans <bde@zeta.org.au> Cc: John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG, Peter Pentchev <roam@orbitel.bg>, Nate Williams <nate@yogotech.com> Subject: Re: new kldpath(8): display/modify the module search path Message-ID: <3B30DB35.493B0D92@mindspring.com> References: <Pine.BSF.4.21.0106201942360.23554-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B30DB35.493B0D92>