Karmic linux-restricted-modules (may it rest in peace)
tim.gardner at canonical.com
Wed May 6 20:20:17 BST 2009
Mario Limonciello wrote:
> Hi Tim:
> Tim Gardner wrote:
>> 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,
>> 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.
You are undoubtedly correct. However, since the wl driver is mostly a
binary blob, I can't fix the bugs anyway, so the reports already go
largely ignored. AFAICT the only effective response we've had from
Broadcom is when they've had contractual OEM obligations. That kind of
relationship doesn't work so well for an open source distro.
>> 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
> 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 no hard numbers. Perhaps Scott could come up with some. The issue
for Karmic, though, is that my boot time budget is so small that _any_
unnecessary boot delays are getting cut.
>> 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.
I'm aware of the pain this move will cause, but its likely no worse then
the transition to DKMS for nVidia and ATI.
> 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).
I'm not sure what can be done about this, other then to just take the
hit. IIRC we don't support 3D accel for compiz, so having fewer features
on the Live CD is already acceptable.
> 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.
I think the upgrade decision could be made by Jockey, e.g., install the
wl DKMS package if its not currently blacklisted, _and_ the PCI ID
exists on the platform.
> 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.
OEM issues tend to get handled a bit differently. With their focus on
netbooks we may very well have an OEM only wl package. How wl is
packaged is gonna be up to them.
Tim Gardner tim.gardner at canonical.com
More information about the kernel-team