[RFC] Inclusion of RT2860 driver

[Matt Zimmerman]

On Tue, Sep 09, 2008 at 06:16:00PM -0400, Stefan Bader wrote:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/210725
> 
> The above bug asks for inclusion of the rt2860 driver into Ubuntu (Hardy LUM or
> at least Intrepid). The rt2xx project does not support this HW but as indicated
> in the bug report the latest driver provided by ralinktech is now working.
> I went through all the pieces mentioned in the report and looked at the changes
> on top of the current driver on the ralinktech web page.
> There are 4 patches, 2 cover compatibility issues and 1 just prevents some
> unwanted installation. The remaining patch adds a wpa supplicant special case
> with comments that this is for EEEPC (so I take it this will probably a major
> users base).
> The required firmware seems to be distributable to me (at least there is a
> license file which allows distribution).
> The most uncommon part probably is that the driver wants some configuration
> data (a file) in /etc/Wireless/...
> 
> The question now is whether we want to provide that driver as a part of the
> kernel package (in the ubuntu tree) or as a separate dkms package. This is
> probably mainly a question of policies. Is it desired to have an additional
> firmware in the kernel package? Should the kernel package create files in /etc?
> A dkms package would make the driver simpler to update without the need to
> release a new kernel package. The downside might be that smaller systems
> (available file system space and CPU power) might not want the compile overhead
> (I am not sure how well the EEEPC would fare there).
> What are the thoughts on this?

Kernel packages, because we support having multiple versions installed
simultaneously, should probably only provide files which are appropriately
versioned (like the module directories and /boot/*).  If
/etc/Wireless/foo.conf is included, it will cause a conflict with a future
ABI-incompatible version of the package.

As to what should be done with DKMS vs. in the kernel packages, assuming
this is a GPL driver, it seems more natural to build it with the kernel,
particularly as a step toward being merged upstream.  Shipping additional
firmware certainly shouldn't be an issue.

An in-tree driver also has the advantage of being available in udebs and
usable on systems which may not have a compiler (eg. space-constrained or
security-paranoid environments).

-- 
 - mdz