Karmic linux-restricted-modules (may it rest in peace)
tim.gardner at canonical.com
Tue May 5 15:22:51 BST 2009
The linux-restricted-modules package has been used historically as a way
to deliver drivers that contain binary components, hence their
restricted nature. Some of these drivers may not be strictly legal in
their fully linked form in all of the countries in which they are used.
Regardless of the legality of these drivers, I have 3 general issues
with the package:
1) All drivers in LRM have a binary component which taint your kernel.
You'll get zero love from upstream if you report a bug with a tainted
2) Binary components are so difficult to debug that few will bother,
3) The components comprising these drivers are not fully linked until
boot time, which extends your boot time by a fixed amount (and also
depends on binutils-static). Note that LRM is installed on every
machine, regardless of whether or not the drivers contained therein are
I've been whittling the list of LRM drivers with each release. For
Karmic, that list is down to 2 drivers; ltmodem and Broadcom (madwifi is
_finally_ effectively superseded by ath5k/ath9k and will no longer be
carried for Karmic).
Broadcom has some serious architectural issues, not the least which is
an enormous binary blob which contains _all_ of the 802.11 protocol
stack presented as a monolithic ethernet driver using WEXT, _plus_
irreconcilable runtime conflicts with SSB (upon which b44 ethernet depends).
My goal for Karmic is to drop LRM altogether. However, before I step off
that precipice, I need to find out what folks think about the
alternatives. I'm quite happy to develop DKMS packages for these
remaining drivers, but not everyone thinks it an appropriate solution.
See http://linux.dell.com/projects.shtml#dkms for a quick primer.
Are there other alternatives? Preferably solutions that don't involve
shipping binary blobs on the Karmic CDs.
Tim Gardner tim.gardner at canonical.com
More information about the kernel-team