Re: policy on GPL'd drivers?
From: Daniel O'Connor (doconnor_at_gsoft.com.au)
Date: 05/29/03
- Previous message: Mike Makonnen: "Re: Libthr stable enough for testing"
- In reply to: Steve Kargl: "Re: policy on GPL'd drivers?"
- Next in thread: Marcin Dalecki: "Re: policy on GPL'd drivers?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: Steve Kargl <sgk@troutmask.apl.washington.edu> Date: Thu, 29 May 2003 13:32:47 +0930
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 _______________________________________________ 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"
- Previous message: Mike Makonnen: "Re: Libthr stable enough for testing"
- In reply to: Steve Kargl: "Re: policy on GPL'd drivers?"
- Next in thread: Marcin Dalecki: "Re: policy on GPL'd drivers?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
