From owner-freebsd-current@FreeBSD.ORG Wed May 28 10:10:24 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44D0A37B405 for ; Wed, 28 May 2003 10:10:24 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8B9743F93 for ; Wed, 28 May 2003 10:10:23 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9/8.12.9) with ESMTP id h4SHA7M7092138; Wed, 28 May 2003 10:10:11 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200305281710.h4SHA7M7092138@gw.catspoiler.org> Date: Wed, 28 May 2003 10:10:07 -0700 (PDT) From: Don Lewis To: imp@bsdimp.com In-Reply-To: <20030528.031403.32720860.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org Subject: Re: policy on GPL'd drivers? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2003 17:10:24 -0000 On 28 May, M. Warner Losh wrote: > In message: <200305281524.10145.doconnor@gsoft.com.au> > "Daniel O'Connor" writes: > : 2) You can't control where the module gets put - arguably this isn't a > : calamity, but I think it makes more sense for the modules to end up in > : /boot/modules, or some analog to it that is in $PREFIX. > > It should go in /boot/kernel, and not into $PREFIX, but that's a > philisophical problem I have with ports. ALL modules should be in /, > imho, since you don't know if the module is required to mount /. Another really good reason is that this is more likely to do the correct thing if you do a major system upgrade, like jumping from 4.x to 5.x, which are very likely to require different versions of the module, and discover some sort of problem when you boot the new kernel to test it before proceeding to the installworld step. The right thing should happen when you fall back to /boot/kernel.old, or /boot/kernel.itusedtowork, etc.