On Wed, 2008-05-21 at 20:53 -0300, Alexandre Oliva wrote: > On May 21, 2008, David Woodhouse <dwmw2@xxxxxxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
