Karmic linux-restricted-modules (may it rest in peace)

[Mario Limonciello]

Hi Tim:

Tim Gardner wrote:
> <snip>
>
> 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
> kernel.
>
> 2) Binary components are so difficult to debug that few will bother,
> including myself.
>   
Although of these are all valid concerns, bug reports containing
broadcom's WL or ltmodem aren't going to away just because the default
scenario doesn't load the kernel modules.  Undoubtedly, users would
still be activating the drivers via Jockey.
> 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
> required.
>   
Do you by chance have data to represent how much time is spent on modern
hardware linking these modules?  Is it to the point that it is relevant
and a significant improvement otherwise?
> 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.
>   
With this kind of proposal, I think the biggest thing you need to be
cognizant of is the usability regressions, upgrade implications, and
possible consequences that extended teams that leverage the distro
release will feel from this type of change.

With regard to usability: for 8.04.2, 8.10, and 9.04 anyone with a
new(ish) Broadcom card has been able to use the driver on a live disk
without much trouble.  if the user had b44/ssb loaded, for 8.10 and 9.04
there is a Jockey action that will go and set up some modprobe magic to
adjust the order things loaded.  From a user's perspective, their
wireless would no longer "just work" on live media.  How important this
is to development teams versus end users may be an item up for
discussion, but I've heard from many people how happy they were wireless
"just worked" for  them with 8.10 and 9.04 (knowing that they had a
Broadcom solution).

So at a minimum I'd expect if a DKMS solution was to replace LRM, it
should still be available on the live media for users to users to be
able to activate.  Jockey and Ubiquity would both need to be modified to
reflect this type of behavioral change too.  Currently Jockey doesn't
run on the live media, and Ubiquity won't copy over anything that you
installed during the live session.

As for upgrade implications, you would either have to break the upgrade
for everyone using wl by not automatically transitioning people to the
DKMS deb, or unnecessarily pull in DKMS and the driver package for
everyone that was using LRM with an earlier release.

Given the recent release of an updated UNR for 9.04 and the apparent
push on the kernel-team ML to get all of the Canonical's OEM service
teams' content updated in the distro, I'm sure they'll have some
feedback to weigh in here too as this may be disruptive for them.

Regards

-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello at dell.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20090505/af026267/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20090505/af026267/attachment.sig>