From owner-freebsd-current@FreeBSD.ORG Tue May 27 20:33:20 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 C6CC237B401 for ; Tue, 27 May 2003 20:33:20 -0700 (PDT) Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by mx1.FreeBSD.org (Postfix) with SMTP id 5D82543F3F for ; Tue, 27 May 2003 20:33:20 -0700 (PDT) (envelope-from q_dolan@yahoo.com.au) Received: from vdub.onthenet.net (HELO ?172.22.1.10?) (q?dolan@203.10.89.16 with plain) by smtp.mail.vip.sc5.yahoo.com with SMTP; 28 May 2003 03:33:19 -0000 From: Q To: Scott Long In-Reply-To: <3ED4294B.4040108@btc.adaptec.com> References: <200305281147.53271.doconnor@gsoft.com.au> <3ED4294B.4040108@btc.adaptec.com> Content-Type: text/plain Organization: Message-Id: <1054092793.1429.39.camel@boxster> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 28 May 2003 13:33:14 +1000 Content-Transfer-Encoding: 7bit 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 03:33:21 -0000 Don't overreact. I'm not suggesting taking the linux approach of versioning every module. But rather allowing the loader or a module (most likely a 3rd part or from a port) the ability to make a decision based on some internal revision/date based "version" as to whether it is safe to proceed to load. I am thinking of ports like rtc, ltmdm or Vmware here.. where it is not uncommon that they require reinstalling after an upgrade. I have experienced kernel panics on several occasions from out of date vmware kernel modules. Seeya...Q On Wed, 2003-05-28 at 13:13, Scott Long wrote: > Q wrote: > > I have been burnt by this in the past also. I think that it would be > > useful if you could allow kernel modules to be bound to a particular > > kernel "version/date/whatever", and have external modules refuse to load > > and/or complain if the kernel is upgraded. This should prevent > > unnecessary kernel panics when you upgrade. The Linux kernel has been > > doing this for years. > > > > Seeya...Q > > > > For the love of god, no! This creates a support nightmare. What > happens when a user installs his system and recompiles the kernel > without changing the source at all? His modules won't work, but > there is no reason why they shouldn't. What if one of those now > non-working modules is a driver for his hard drive? > > Scott > > > > On Wed, 2003-05-28 at 12:17, Daniel O'Connor wrote: > > > >>On Tue, 27 May 2003 22:13, David Leimbach wrote: > >> > >>>>However the idea is that all GPL infected stuff be isolated, allowing a > >>>>fully working kernel without GPL stuff in there. > >>> > >>>Sounds like a "kernel module" is the way to go then. Perhaps it could > >>>exist in the ports tree instead of the mainline kernel sources :). I > >>>know > >>>I'd be happy with that... the problem is hosting the driver since I am > >>>sure > >>>"patching" it won't be enough to map the linux innards to freebsd's. > >> > >>There are already a number of kernel modules in the ports tree (eg nvidia > >>drivers, ltmdm modem driver, aureal sound driver, etc). > >> > >>The only downside is that there are no hooks into the build process so you > >>have to be VERY careful when you update your kernel, or you get panics :( > >> > >>(I found this recently, some change broke all of my 3rd party modules and > >>caused panics when I tried to load them). > >> > >>I would really like some way of getting external modules rebuilt at the same > >>time as buildkernel and friends, otherwise you have to remember to rebuild > >>the affected ports, and it is a pain in the ass. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"