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

kernel firmwares: GR proposal


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


Attachment: signature.asc
Description: Digital signature

Reply to: