From owner-freebsd-arch Tue Jul 18 14: 7:58 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-51.dsl.snfc21.pacbell.net [63.202.177.51]) by hub.freebsd.org (Postfix) with ESMTP id 1F49D37BBD5 for ; Tue, 18 Jul 2000 14:07:52 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id OAA18973; Tue, 18 Jul 2000 14:13:59 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200007182113.OAA18973@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Marcel Moolenaar Cc: arch@FreeBSD.ORG Subject: Re: Multiple kernels / module search path In-reply-to: Your message of "Tue, 18 Jul 2000 09:20:39 PDT." <397483D7.DFEC9BBC@cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jul 2000 14:13:59 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The problem is with versioning. If I add 3rd party module foo.ko to > modules, while it actually is a module for kernel 'kernel.bar' *and* > kernel and kernel.bar are sufficiently incompatible, then kernel won't > boot (for example) if the module is loaded at boot time. > > Or, if kernel.bar is booted and I want to load foo.ko, I might pick up > the version from /modules if I don't happen to have a foo.ko in > /modules.bar, which may be sufficiently incompatible and cause a kernel > panic. This has already been discussed to death, and consensus has been as follows: When a kernel is built and installed in the default fashion, a directory 'kernel' will be created. This directory will contain a file kernel.ko (the core kernel module) and any other modules configured to be built with the kernel (at this time, that's all of them). The actual name of this directory is of course subject to modification, and its final location (/, /boot, etc.) hasn't really been tied down. Entirely separately, there is a 'modules' directory, which is listed second on the module search path, and which contains modules not directly tied to the exact running instance of the kernel. ie. third-party modules, meta-information (splash screens, SCSI quirk tables, etc.). Note that with module versioning, you can't load an incompatible module, so that's not actually an issue. As long as there's a compatible version of a module somewhere on your search path, you'll be fine. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message