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 -- ENOSIG
Attachment:
signature.asc
Description: Digital signature