From owner-freebsd-arch Wed Jul 19 16:27:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from racine.cybercable.fr (racine.cybercable.fr [212.198.0.201]) by hub.freebsd.org (Postfix) with SMTP id E354D37B764 for ; Wed, 19 Jul 2000 16:27:02 -0700 (PDT) (envelope-from lefevre@citeweb.net) Received: (qmail 1679143 invoked from network); 19 Jul 2000 23:27:01 -0000 Received: from r224m65.cybercable.tm.fr (HELO gits.dyndns.org) ([195.132.224.65]) (envelope-sender ) by racine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 19 Jul 2000 23:27:01 -0000 Received: (from root@localhost) by gits.dyndns.org (8.9.3/8.9.3) id BAA68960; Thu, 20 Jul 2000 01:26:56 +0200 (CEST) (envelope-from lefevre@citeweb.net) Posted-Date: Thu, 20 Jul 2000 01:26:56 +0200 (CEST) To: Marcel Moolenaar Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: Multiple kernels / module search path References: <200007182113.OAA18973@mass.osd.bsdi.com> <3974CB11.388FE532@cup.hp.com> Reply-To: clefevre@citeweb.net X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C From: Cyrille Lefevre To-List: freebsd-arch@freebsd.org Date: 20 Jul 2000 01:26:55 +0200 In-Reply-To: Marcel Moolenaar's message of "Tue, 18 Jul 2000 14:24:33 -0700" Message-ID: Lines: 48 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Marcel Moolenaar writes: > Mike Smith wrote: > > > > > 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: > [snip] > > Ok, I'll make {build|install}kernel behave the same as the traditional > way only and not add the ability to install multiple kernels. We can > always revisit these targets when the improved infrastructure is in > place. there is one thing I don't understand in this thread. you are saying than modules are different from kernel to kernel. I suppose this is true if you build modules as part of world (the old way) and not as part of the kernel. where, if the src tree as been updated between the workd and the kernel. I'm right ? if you build the world and the kernel in the same time, even if you have multiple kernels (read your own and GENERIC), it should not be a problem to have one and only one module directory. do you understand what I mean ? and what I understand is that the building of modules as part of the kernel and not of the world is to avoid conflicts if the src tree has been updated. IMHO, to left the root directory clean, it would be better to create /modules/WHATEVER subdirectories than /modules.WHATEVER. the idea to have kernel.ko in /modules/WHATEVER is interresting. what is the problem about to have /:/boot:/modules/WHATEVER:/modules as the modules search path ? another problem is to say to the boot loader which kernel to load. what about loader_conf_files=" \ /boot/boot.conf /boot/loader.conf /boot/loader.conf.local" where boot.conf just contain kernel="/modules/WHATEVER/kernel" which is updated a kernel installation ? Cyrille. -- home: mailto:clefevre@citeweb.net work: mailto:Cyrille.Lefevre@edf.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message