From owner-freebsd-current@FreeBSD.ORG Wed May 28 20:19:02 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 9D63537B401 for ; Wed, 28 May 2003 20:19:02 -0700 (PDT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0C3A43F3F for ; Wed, 28 May 2003 20:19:01 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) h4T3IxPR033767; Wed, 28 May 2003 20:18:59 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)h4T3IwpA033766; Wed, 28 May 2003 20:18:58 -0700 (PDT) Date: Wed, 28 May 2003 20:18:58 -0700 From: Steve Kargl To: "Daniel O'Connor" Message-ID: <20030529031858.GA33495@troutmask.apl.washington.edu> References: <200305281350.27953.doconnor@gsoft.com.au> <200305281840.46645.doconnor@gsoft.com.au> <20030528142837.GA30174@troutmask.apl.washington.edu> <200305290920.23291.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200305290920.23291.doconnor@gsoft.com.au> User-Agent: Mutt/1.4i cc: scott_long@btc.adaptec.com cc: q_dolan@yahoo.com.au cc: "M. Warner Losh" 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: Thu, 29 May 2003 03:19:02 -0000 On Thu, May 29, 2003 at 09:20:23AM +0930, Daniel O'Connor wrote: > On Wed, 28 May 2003 23:58, Steve Kargl wrote: > > > > Because there are other, more elegant ways of dealing with these > > > > things. I don't like /usr/local/src anything, which was the main > > > > complaint. > > > > > > If there are more elegant solutions I would like to know what they are. > > > > > > I agree it isn't a great solution, but I can't see what is better. > > > > For GPL modules, put them in src/sys/gnu. If you don't > > want bloat, then use cvsup and a refuse file to not > > retrieve the sys/gnu. See the discussion that occurred > > many years ago when maestro3 support was committed to > > the tree. > > > > For non-viral licensed code, put it in its proper > > place in the sys/ hierarchy. Then use a WANT_XXX=yes > > knob in the /etc/make.conf to cause XXX to be built. > > You are describing how it happens now, not WHY it happens like that. The WHY is obvious. The modules (1) get rebuilt with the kernel. (2) get installed with the kernel. (3) get moved to /boot/kernel.old when a new kernel is installed. (4) *Ideally*, if an API changes, the modules will be updated by the developer/committer who breaks the modules; otherwise, a person experiencing the breakage can ask for the commit to be backed out. (Note, the *ideally* acknowledges that 64-bit platforms seem to suffer API breakage more than ia32). > I think the existing solution has problems, and would prefer some external > hooks for 3rd party modules. If you mean "third party modules without available sources", then (1) The module should work for whatever -RELEASE i for which it was built. (2) If you upgrade the OS, the module may or may not work. (a) If it works, well aren't you lucky. (b) If it doesn't work, then (i) Ask the vendor for an update. (ii) Hack around the breakage. (iii) Downgrade to the *PROPER* -RELEASE. -- Steve