Re: RC bugs in Linux
Robert Millan wrote:
>Bear in mind that violating the DFSG is a release-critical bug, whereas
>disabling upstream drivers is not. And AFAIK disabling tainted drivers is a
>trivial task, but splitting the binary-only blobs into non-free isn't.
>Therefore if the latter requires long-term work, the former has to take
>priority. So the question is, does it require long-term work?
This is highly driver specific. If the driver loads the firmware in
interrupt context, or while holding a spinlock, the
conversion is rather tricky, because the firmware must be loaded from
userland beforehand in process context and saved until needed. If the
driver loads the firmware in process context, then the conversion is easy.
(The driver can hold locks on the peripheral hardware resources, of course.)
Some examples which I've actually looked at.
* sound/oss/ymfpci_image.h
* sound/pci/ymfpci/ymfpci_image.h
Sourceless microcode with no permission to distribute.
These files have to be removed; they can't even go in non-free.
So the ymfpci drivers have to be disabled, period. See bug 243022.
* drivers/char/drm/r128_cce.c
* drivers/char/drm/radeon_cp.c
In progress. Splitting the binary blobs out was trivial and is
done.
Unfortunately, the blobs still need accurate copyright statements and
a proper license to be distributable. The copyright statement on the files
they're in almost certainly does not apply to them.
Preventing X Windows from crashing when the blobs are missing was
less trivial (bugs in XFree86) and is in progress; and because of the
distributability problem, it is especially important. Also, these are
truly common drivers, unfortunately.
* drivers/char/drm/mga_ucode.h
Should be trivial to split out, much like the radeon and r128 ones. Except
that these *do* have accurate copyright statements and licenses, so they're
distributable. (Hopefully there will not be a similar X Windows bug to the
one in Radeon.)
* drivers/net/tg3.c
Quite difficult to convert to userland loading. I had it working, but
unfortunately the version now in the Debian kernel package apparently doesn't
always work and I haven't managed to debug it yet.
Luckily most tg3 hardware doesn't need the firmware and the current version
of the driver in the Debian kernel works fine without it. :-) This is a case
where removing the firmware loading doesn't cripple the driver, and there
will probably be others.
* drivers/usb/emi26_fw.h
More non-distributable stuff. See bug 242895.
--
So, we have many different cases of non-free firmare:
* firmware which isn't necessary for the driver
Here, the correct short-term solution is to remove the firmware, but not
the whole driver
* non-distributable firmware which is necessary for thedriver
Here, the driver must be removed.
* firmware which is easy to separate
It should be separated.
* firmware which is hard to separate (but necessary and distributable)
This y'all can argue about, but I think it's not the majority, so deal with
the clear-cut cases first!
--
I think it will be a lot more reasonable to have one bug per driver, if the
kernel maintenance team is actually serious about handling these. I'd break
Herbert's merged bugs apart again and probably split them up further.
--
There are none so blind as those who will not see.
Reply to: