LKML thread about (re)moving firmware within the kernel

[David Woodhouse]

On Sat, 2008-05-31 at 12:15 -0300, Alexandre Oliva wrote:
> On May 31, 2008, David Woodhouse <dwmw2 at infradead.org> wrote:
> 
> > 1. Who the target audience of your mail is.
> 
> Those who are reacting to your proposal with anti-ideology rhetoric.
> 
> > 2. What they currently think about firmware blobs.
> 
> AFAIK they don't care.  They use it when it's convenient, they don't
> when it isn't.
> 
> > 3. What _their_ concerns are.
> 
> Convenience, and being able to ship as much firmware as convenient
> without being bound by concerns such as users' freedom.
> 
> > 4. How your mail addresses _their_ concerns
> 
> The intent was to attempt to remove the anti-ideology reflex from the
> thought processes, explaining that, in spite of the suspicions, the
> outcome of this proposal does not advance our cause.
> 
> > 5. How your mail will thus affect their opinion
> 
> Maybe it won't, if they don't believe me because they don't understand
> what my goals and my values are.  I already know they don't agree with
> them, but I'm counting on their ability to put themselves in my own
> shoes and realize that this proposal does no good for me.
> 
> > 6. What you hope the outcome of your mail will be
> 
> BIG FLAMEWAR! :-)
> 
> Seriously, I hope, after people read this e-mail, your proposal gets
> evaluated on technical grounds, not rejected on suspicions on your
> being part of the big RMS conspiracy against them ;-)
> 
> >> > First of all, IIRC last time Debian discussed the issue of non-Free
> >> > firmware in the kernel, they decided they wanted to ship it.  DavidM,
> >> > to the best of my knowledge, your assumption that Debian would be
> >> > interested in a change like this for the reasons you seem to assume it
> >> > would be is unwarranted.
> 
> > They actually _wanted_ to ship it? Certainly not in the kernel proper.
> > They _wanted_ to move it to non-free, at least. But since they didn't
> > have the technical means to do that in a fashion which would allow
> > people the choice of continuing to use the affected drivers, they chose
> > not to split it out.
> 
> Back then, they even *added* more non-Free firmware to their kernels,
> so I guess you may be referring to a more recent discussion I wasn't
> aware of.

I was looking through the Debian bug about removing firmware.

> > We have a similar situation with Fedora. We _want_ to ship the firmware
> > separately, so that we can do 'Freedom' spins of Fedora which don't
> > include it at all. But for now we can't realistically do that.
> 
> because...  kernel, kernel-smp, kernel-PAE, in both vanilla and -debug
> variants, is too much already?  Oh, and there's kernel-xen, too.
> Surely adding kernel-libre to the mix wouldn't be such a terrible
> thing, especially with the little amount of work it takes to track the
> corresponding non-Free kernel builds day-to-day.  The fact that it
> would be built out of a separate tarball is irrelevant.  We're talking
> 50MB in a set of several DVDs of sources.  It really amazes how far
> people will go to resist just a small advance in freedom.

This is a discussion which was already covered in the Fedora context.
The answer now, as it was then, is that Fedora would love to ship a
kernel without the non-Free firmware blobs, but it must not be an
alternative kernel (the others you mentioned are each for different
hardware, not a user choice), and it must not just _break_ the drivers.
The user must have the choice of obtaining a firmware from elsewhere and
using it with the driver we ship.

And yes, Fedora _would_ continue to ship that firmware by default, just
as it does other firmwares -- in separate packages from separate
sources.

> And if Fedora and Debian don't care enough to ship a Free kernel that
> already exists and is well maintained and kept up-to-date with the one
> they've come to love, this just shows where they stand and how much
> they value freedom.

Fedora would love to ship a Free kernel, but will not do so at a cost of
just breaking a large number of drivers. I believe that Debian made the
same decision. What I'm doing will allow us to ship a Free kernel.

> > But Alex, there _are_ no other pieces of non-Free software in the
> > kernel.
> 
> You pointed me to "false positives" yourself.  We're failing to
> communicate.

I've looked at a table of {register,value} settings and said 'hey, I
don't really think this needs to be ripped out'. I've typed similar
tables into drivers, working through a datasheet to calculate them for
myself. The source of these numbers was the datasheet and my brain.
Would true Freedom mean that I have to include both of those in the
tarball?

I believe that we're talking about code which looks like this...

        {0xce, 0x00},           /* set default memory clock */
        {0xcc, 200 },           /* MCLK ratio M */
        {0xcd, 18  },           /* MCLK ratio N */
        {0xce, 0x90},           /* MCLK divisor = 2 */

        {0xc4, 209 },
        {0xc5, 118 },
        {0xc7, 32  },
        {0xcf, 0x06},
        {0x09, 0x01},           /* IO Control - CRT controller extensions */
        {0x0a, 0x02},           /* Frame buffer mapping */
        {0x0b, 0x01},           /* PCI burst write */
        {0x40, 0x03},           /* Memory access control */
        {0x80, 0x82},           /* Pixel pipeline configuration 0 */
        {0x81, 0x12},           /* Pixel pipeline configuration 1 */
        {0x82, 0x08},           /* Pixel pipeline configuration 2 */

        {0xd0, 0x0f},
        {0xd1, 0x01},

Ok, not all of it is so well-commented, but do you want to remove _all_
non-commented code from the tree? :)

> The issue is not what license the code provided under.  The issue
> is whether all 4 freedoms are respected.  The portions you called
> false positives are just as non-Free Software as the firmwares you're
> moving out.  And since these are not firmware, I suppose they're not
> going to be handled with the firmware loading mechanism, even though
> in theory they could.

Of course they could. I've been busy converting real firmware first, but
there's no reason any 'blob' can't be loaded that way. Just send
patches.

> And then, there's the issue of obfuscated source code, like the one
> Alan Cox mentioned on fedora-devel in the nv X drivers.  This sort of
> thing is also non-Free Software.  And if the gNewSense folks that are
> auditing the kernel sources by hand looking for this stuff do find
> such occurrences, we'll take them out as well.  But even if they do,
> unless the kernel had policy against adding this sort of code, we
> can't entrust it with our efforts to ensure our kernel remains Free.

That's a separate issue, yes.

> > That seems like nonsense to me, too. The 'deblob' scripts need updating
> > from kernel to kernel anyway,
> 
> Yep.  Minor.  And I generally catch these updates during the -rc
> cycles anyway.  It's still more work if it changes than if it doesn't.

Not a lot more work. You just end up removing entries from the list of
things to deblob list, as they get converted to request_firmware() one
by one.

> > and we're rapidly getting to the point
> > where all you need to do is 'rm -rf firmware/'.
> 
> That's a faulty assumption.  Your approach does NOT solve the whole
> problem we do, even though you appear to believe that it does.  Your
> assessment of 'false positives' shows you've misidentified the problem
> we're trying to solve, so you went for something that would solve only
> part of it.
 ...
> > This whole thing is being done to advance your goal, which I share in
> > this particular instance. And it looks like you intend to argue
> > _against_ its inclusion.
> 
> As I wrote in my e-mail, it was misguided, and now I begin to
> understand why: you appear to have misidentified what the goal is,
> limiting it to a point that makes it seem much narrower.

I don't think I've misidentified the goal. I'm making progress by
concentrating on one part of the overall goal. I'm not attempting to end
world hunger in one strike.

Once we've removed all the source-less blobs from the kernel, then we
can move on to the next problem...

-- 
dwmw2