policy on GPL'd drivers?

[Q]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"