[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kernel firmwares: GR proposal

Hash: SHA1

I second the below GR proposal.


Sven Luther

 || 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
 || -- 
Version: GnuPG v1.4.5 (GNU/Linux)


Reply to: