Seconded. On Wed, Aug 30, 2006 at 11:06:54PM +0200, Frederik Schueler wrote: > Overview: > > The Linux kernel source contains device drivers that ship with firmware > files provided by the hardware manufacturer. They are uploaded during > the driver initialization to the corresponding hardware device. > > Some of these binary image files are provided as a hexdump of register > bank settings, others consist in fact of compiled binary code which is > executed on the hardware device. > > Any device driver in the Linux kernel is freely available in source > format and licensed under the GPL2. For many device drivers with > attached firmware, the firmware image is freely distributable along > with the corresponding driver. The most common source format for > firmwares is the hexdump char array. It is almost impossible to > distinguish between register dumps and binary code without asking the > device manufacturer who provided the firmware. > > Removing every firmware which is distributed as hexdump only will > cripple the kernel to an extent where it becomes unusable for most of > our users, because popular network and scsi devices are among the > drivers in question. Without these drivers, the user's system might not > be installable at all. > > > The current situation: > > We achieved a lot of progress compared with the situation in 2.6.8 (the > kernel that shipped with sarge). We were able to convince upstream that > a firmware loader is a good thing, and that firmware and kernel code > should be separated. This firmware loader was added in 2.6.13, and > meanwhile, more than 40 drivers have been converted to the new > infrastructure. However, this is not yet finished, and some important > drivers still use the old method. There will be a day where we can drop > the remaining legacy, but we are not there yet. > > Also, though the firmware loader allows us to put the firmware where it > belongs to (main or non-free, depending on the case), the installer can > as of now only take udebs from main. Fixing this is not too hard, but > it is doubtful whether we can fix this in time for etch, and we do not > want to depend on that (and even then, we still would have non-free > firmware, see above). But since there is lots of hardware which needs > firmware for correct operation, the installer would not work for > mainstream hardware otherwise. > > There are two ways how to deal with it: > 1. Accept these issues as transitional issues for now; or > 2. Delay etch for some serious time. > > > In our social contract, we promised that the users and the free software > community are our priorities. We firmly believe that our users profit > very much from releasing etch in time, and that this is important enough > that we can accept the transitional status with having a few firmware > images left in main that should belong somewhere else. Of course, > everyone who wants to make the number of such firmware images as small > as possible is welcome to help converting old firmware loaders to the > new standard, and working on the Debian installer. We are happy if this > issues become smaller or even vanishes, but we do not want this to be a > release blocker. > > > So, we propose this GR: > > 1. We affirm that our Priorities are our users and the free software > community (Social Contract #4); > 2. We acknowledge that there is a lot of progress in the kernel firmware > issue; however, it is not yet finally sorted out; > 3. We give priority to the timely release of Etch over sorting every bit > out; for this reason, we will deliver firmware in udebs as long as it is > necessary for installation (like all udebs), and firmware included in > the kernel itself as part of Debian Etch, without further conditions. > > > We want to emphasize that the success of this GR is considered as > necessary by the kernel and release team for successfully delivering etch > in time (and to allow us a successful planning of that). > > > on behalf of the kernel- and release team > Frederik Schueler
--
Prepare for tomorrow -- get ready.
-- Edith Keeler, "The City On the Edge of Forever",
stardate unknown
signature.asc
Description: Digital signature
