From owner-freebsd-current@FreeBSD.ORG Wed May 28 21:03:10 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 280AB37B401 for ; Wed, 28 May 2003 21:03:10 -0700 (PDT) Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52F3C43F3F for ; Wed, 28 May 2003 21:03:05 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from localhost (localhost [127.0.0.1]) by cain.gsoft.com.au (8.12.9/8.12.8) with ESMTP id h4T42mgD008359; Thu, 29 May 2003 13:32:48 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Steve Kargl Date: Thu, 29 May 2003 13:32:47 +0930 User-Agent: KMail/1.5 References: <200305281350.27953.doconnor@gsoft.com.au> <200305290920.23291.doconnor@gsoft.com.au> <20030529031858.GA33495@troutmask.apl.washington.edu> In-Reply-To: <20030529031858.GA33495@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305291332.47580.doconnor@gsoft.com.au> X-Spam-Score: -1.5 () CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) 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 04:03:10 -0000 On Thu, 29 May 2003 12:48, Steve Kargl wrote: > > 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. No, I mean third party modules with available sources, but not necessarily up to scratch code wise, or license wise. I think if the code is committed there is a much greater onus to make sure it doesn't break, and it incrases the load on everyone testing things. My basic point is that people want to use 3rd party modules - they aren't committers so it's not like they can just wack some code into the repo. The alternative for them is manual patching or using the ports framework - this is OK but suffers integration problems. I just want some way of rebuilding my 3rd party modules with my kernel that doesn't involve me having to jump through hoops :( I don't see what the down side of rebuilding 3rd party modules with a buildkernel and friends is. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5