Re: policy on GPL'd drivers?

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