On Thu, Mar 10, 2005 at 11:10:56PM +0100, Frederik Schueler wrote: > Hello, > > The general resolutions 2004-003 and 2004-004 in mind, I would like to > find a consensus among the kernel-team members on how to deal with > binary-only firmware blobs in the kernel, now for sarge, and for later > releases. > > Bugs like #298743 show we have users needing the currently pruned > drivers, and I need some of them too myself - both for my private boxes, > as well as at my workplace. Having the drivers removed without a > replacement in non-free, like for example custom buildable module > packages and udebs to be loaded at installation time, is a not tolerable > situation. > > If you have a closer look at the kernel-sources we distribute, only a > few binary firmware drivers are removed at all. The dri modules for > radeon and mga, the advansys scsi driver, soundblaster 16 and many more > drivers with binary firmware are still in place. Even questionable > examples like the intel e100 driver, which applies a small (binary) > patch to the firmware at initialization time. > > In my opinion, this situation is discriminatory against users who want > to run Debian on a system containing affected hardware. > > > In short, I would like to propose the following: > > 1. we remove the pruning from current sarge kernels, and release kernel > sources complete with all drivers as distributed on kernel.org > > 2. we agree on how to handle binary firmware in future releases, > in the light of GR 2004-004:
Notice that invoking 2004-004 is problematic, since it only overrides the cleanup-solution of 2004-03, which applies to non-software in the old interpretation. I don't think you can argue that these firmware blobs are not software though, altough the fact that the 2004-03 GR that 2004-04 overrides is about 'editorial changes' may let us some options to slit in stuff under cover of service to the users. In any case i think that keeping mutilated drivers in main is a problem, and is going to cause us support nightmares in the long run, so i would rather we don't build those in main at all. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
