Plan for tomorrows (20080522) FESCO meeting

[David Woodhouse]

On Wed, 2008-05-21 at 20:53 -0300, Alexandre Oliva wrote:
> On May 21, 2008, David Woodhouse <dwmw2 at infradead.org> wrote:
> 
> > On Wed, 2008-05-21 at 18:21 -0300, Alexandre Oliva wrote:
> >> I believe I've already explained why I can't do that.  I refuse to
> >> distribute non-Free Software, and posting a patch that removes these
> >> bits amounts to posting those very bits.
> 
> > Really, that's a stupid objection. Just post it in ed form.
> 
> Assuming that's acceptable upstream. I sort of doubt it,

Post them to me; I'll convert them to 'diff -u' for you and send them
on.

> Another I still haven't mentioned is that I have no interest in being
> harrassed and verbally abused like the last discussion about freedom
> issues I got into there.

That is best addressed by making sure you don't come across as a kook.
You need to make it clear that you're not just intending to remove stuff
and run away leaving it broken; for anything you change, you need to
make sure there is a viable working alternative. Saying "oh, but I don't
want to touch it" is a crappy excuse. If you don't want to touch it,
then get someone _else_ to do the work. But don't expect your ed-scripts
to be applied when they're actually causing regressions.

> 
> Now, let me show you why this proposed plan is an impossible mission
> that people are trying to drive me into.  Consider this snippet from
> http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/deblob-2.6.25
> 
>   # SND_KORG1212 - Korg 1212 IO
>   clean_ifdef sound/pci/korg1212/korg1212.c CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL
>   clean_blob sound/pci/korg1212/korg1212-firmware.h
> 
>   # SND_MAESTRO3 - ESS Allegro/Maestro3
>   clean_ifdef sound/pci/maestro3.c CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL
> 
>   # SND_YMFPCI - Yamaha YMF724/740/744/754
>   clean_blob sound/pci/ymfpci/ymfpci_image.h
>   clean_ifdef sound/pci/ymfpci/ymfpci_main.c CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL
> 
> clean_blob() removes long sequences of numbers, whereas clean_ifdef()
> runs unifdef on the named file assuming the named variable is
> undefined.
> 
> Could you honestly tell me, with a straight face and a reasonable
> degree of assurance, that a patch that performs these actions stands
> any chance whatsoever of being accepted upstream?

I'll tell you what I'd do to _improve_ its chances. Would that do?

What I'd do is augment the kernel's firmware class support so that users
can build firmware blobs into their kernel to be accessed through the
firmware class. So the ifdefs in the above code go away -- the user can
just choose to include the blobs in the kernel build or not, as they see
fit, and the driver just invokes the firmware loader and doesn't
actually _care_ whether the firmware comes from within the kernel or
from userspace.

Once you've done that, you (or your minion) can start moving all the
offending uses of firmware blobs over to the firmware class without
_any_ regressions at all, since they'll keep working without even
needing an initrd. 

And after that, you can look at evicting the offending blobs from the
kernel altogether. Since Fedora uses an initrd anyway, we'd probably
choose not to build any of the blobs into the kernel, but to ship them
in a separate package(s). You can then just omit that package from your
compose.

I'm utterly uninterested in any response of "that sounds like work; I
just want to break things" or "I don't want to touch it". Those are the
responses which will get you "harassed and verbally abused" on lkml, or
just ignored by me.

-- 
dwmw2