Date: 28 May 2003 13:33:14 +1000 From: Q <q_dolan@yahoo.com.au> To: Scott Long <scott_long@btc.adaptec.com> Cc: freebsd-current@freebsd.org Subject: Re: policy on GPL'd drivers? Message-ID: <1054092793.1429.39.camel@boxster> In-Reply-To: <3ED4294B.4040108@btc.adaptec.com> References: <C90CF9CA-9040-11D7-941E-0003937E39E0@mac.com> <200305281147.53271.doconnor@gsoft.com.au> <3ED4294B.4040108@btc.adaptec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1054092793.1429.39.camel>